Help entry for makedevs?

Eric Spakman E.Spakman at inter.nl.net
Sat Jan 14 11:00:07 UTC 2006


Rob,
>>
>> The "leaf" taste of makedevs is especially for the LEAF project
>> (http://leaf.sourceforge.net/) where this applet is used to create
>> devices. A long time ago someone came up with an other implementation,
>> which uses a "table" to do the same thing. To not break all existing
>> LEAF
>> branches Erik implemented both in the applet.
>
> That doesn't say what the actual difference is.
>
Because I don't know what the exact differences are :), only why there are
two implementations. But I found this mail in the archives that hopefully
explains it:
http://www.busybox.net/lists/busybox/2004-June/011750.html
It's still not clear to me however...

>
>> Something else, I quickly tested the busybox-1.1.0 release and hitted
>> two bugs:
>> One with chmod, where "chmod -R 660 *" in the /dev directory gives tons
>> of warnings about "following links" on the next entry: lrwxrwxrwx  1 root
>> root      13 Jan 13 12:39  fd -> /proc/self/fd
>>
>> Reverting "Bug 310: be consistent about stat/lstat and chown/lchown to
>> avoid accidentally modifying permissions or ownership when twiddling
>> symlinks." makes it work again.
>
> You don't say what the actual warnings are.  (The text "following links"
> doesn't occur in chmod.c.)  Is the only problem warning messages, or is
> there an actual behavior problem?  (Also, what does the gnu chmod do in
> this situation?  Does its' -R not follow symlinks at all?)
>
I'm sorry, I wrote it down from memory (which isn't as accurate as I
hoped). This is the exact output I get:
/dev# chmod -R 660 *
chmod:
fd/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/0:
Too many levels of symbolic links
chmod:
fd/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/1:
Too many levels of symbolic links
chmod:
fd/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/2:
Too many levels of symbolic links
......
And this goes on forever.

When I revert the last change to chmod like this
-               if (! recursive_action (*argv, recursiveFlag, TRUE, FALSE,
+               if (! recursive_action (*argv, recursiveFlag, FALSE, FALSE,

The problem went away. I'm not sure what GNU chmod does in this situation,
I have to set up a test environment for it.


>> An other bug with "mount -a":
>>
>
> A big rewrite of mount -a handling is sort of in progress.  On hold
> pending my move up north, and I didn't want to hold up 1.1.0 for it
> because it was already far enough behind schedule.
>
I understand.

>> Doing a mount -a with the next (and only) line in /etc/fstab (no mtab
>> support) proc  /proc  proc noauto 0 0 Gives the following error:
>> mount: Mounting (null) on (null) failed: Success
>>
>
> What does "next and only" mean?  (Is there only one line in /etc/fstab,
> or is it next to some other line?)  "failed: Success" is always a fun
> error message.  Good old errno 0.
>
"proc  /proc  proc noauto 0 0" is the only line in /etc/fstab.

An other corner case:
When you do something like this:
mount -nt proc /proc /proc
mount -t tmpfs /dev/root /tmpfs -o size=6M
umount /proc
<copy files to the new tmpfs root>
pivot_root . <new root>
mount -t proc /proc /proc

The output of mount is "(null) on / type tmpfs (rw)" instead of "/dev/root
on / type tmpfs (rw)". It looks like some information is lost after
umounting /proc.

> Basically, mount -a doesn't reinitialize the state of things properly the
>  second and later times through the loop.  It needs restructuring to be
> less complicated.  I'll fix it...
>
> Rob
> --
> Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
> I do not think it means what you think it means.
>
Eric





More information about the busybox mailing list