Help entry for makedevs?
Rob Landley
rob at landley.net
Sat Jan 14 22:22:09 UTC 2006
On Saturday 14 January 2006 05:00, Eric Spakman wrote:
> > 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...
Time for me to read the code, I suspect...
> > 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
Ok, the warning "Too many levels of symbolic links" is what strerror() returns
for ELOOP, and the only way we're going to get an ELOOP error is if it's
returned by the kernel, which means the filesystem _does_ have a path with
too many levels of symbolic links. So your filesystem must have a recursive
symlink loop or we wouldn't be printing this message out in the first place.
That said, busybox could still be wrong if we're not supposed to follow
symbolic links with -R. Let's see...
The spec is here:
http://www.opengroup.org/onlinepubs/009695399/utilities/chown.html
And although it doesn't come out and say how we should handle directory
traversals, I just re-read the -h, -H, -L, and -P options, and it looks like
following symlinks by default, while not a violation of the spec, isn't what
they had in mind either. (It would be _so_ nice if they could state all this
clearly...)
Ok, -h means chown the symlink itself when it's specified on the command line.
(Implying that the alternative is to chown what it points to? But only when
it's specified on the command line, not via -R?
)
-R means recurse, but it implies only into files and directories (I.E. ignore
symlinks). Note that it _says_ any behavior (-H, -L, or -P) is allowed by
default when you don't say. Our default behavior is -L. So we are following
the spec, it's just not doing what you want. (I think what you want is -H.)
When doing -R:
-H means follow symlinks to directories given on the command line, but don't
follow symlinks found in a directory.
-L means follow any symlinks, even in a directory (the behavior we've got
now.)
-P means the recursino works like -h, changing ownership the symlink itself
when it finds them.
Ok, so the spec doesn't care what default behavior we choose. The question
is, what default behavior are people _expecting_? (And do we implement all
the right flags so they can specify when they care?)
> 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.
Our default behavior changed, and the new one screws you up, but according to
the spec is quite valid.
A quick glance at our code says we don't support -H, -L, or -P, but neither
does gnu. I'll try to look into it more closely this evening...
> >> 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.
Should be relatively easy to test, then...
> 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>
So you're using 2.4, then? Or an initrd under 2.6?
> 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.
Actually it's looking like the attempt to lookup /dev/root is failing. We've
got code in there (find_block_device() in libbb) that attempts to determine
which /dev entry tmpfs should belong to, and if your current /dev is empty it
won't find anything.
We've had other reports of that being wonky with regards to df, and it's dog
slow anyway. I need to figure out what all that mess _should_ be doing.
I suspect that the correct approach is to rip find_block_device() out entirely
and instead modify mdev to create a /dev/root symlink pointing to the correct
device based on an examination of /sys. That way if you want to know
where /dev/root lives, you look at /dev/root to see where the symlink points,
and we don't try to play silly games based on magic names the kernel is
feeding us at runtime.
Again, I'll play with that this evening if I get a chance.
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
More information about the busybox
mailing list