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