<snip>
version: coreutils-5.2.1-32.rpm (from SuSE 9.2). Linux kernel 2.6.11.1 (kernel.org version). reiserfs.
Quoting from the chown man page:The following options modify how a hierarchy is traversed when the -R option is also specified. If more than one is specified, only the final one takes effect.
-H if a command line argument is a symbolic link to a directory, traverse it
-L traverse every symbolic link to a directory encountered
-P do not traverse any symbolic links (default)
The info page for chown agrees:`-R' `--recursive' Recursively change ownership of directories and their contents.
`-H' If `--recursive' (`-R') is specified and a command line argument is a symbolic link to a directory, traverse it. *Note Traversing symlinks::.
`-L' In a recursive traversal, traverse every symbolic link to a directory that is encountered. *Note Traversing symlinks::.
`-P' Do not traverse any symbolic links. This is the default if none of `-H', `-L', or `-P' is specified. *Note Traversing symlinks::.
The actual default behavior of chown appears to be to recursively follow symbolic links. To wit:
haydn:~ # mkdir sandbox haydn:~ # cd sandbox/ haydn:~/sandbox # mkdir -p a/aa/aaa haydn:~/sandbox # touch foo haydn:~/sandbox # mkdir b haydn:~/sandbox # cd a/aa/aaa/ haydn:~/sandbox/a/aa/aaa # ln -s ../../../foo foo haydn:~/sandbox/a/aa/aaa # ln -s ../../../b b haydn:~/sandbox/a/aa/aaa # cd ../../.. haydn:~/sandbox # ls -l total 2 drwxr-xr-x 4 root root 120 Mar 9 10:03 . drwx------ 37 root root 2304 Mar 9 10:02 .. drwxr-xr-x 3 root root 72 Mar 9 10:03 a drwxr-xr-x 2 root root 48 Mar 9 10:03 b -rw-r--r-- 1 root root 0 Mar 9 10:03 foo haydn:~/sandbox # chown -R nobody:users a haydn:~/sandbox # ls -l total 2 drwxr-xr-x 4 root root 120 Mar 9 10:03 . drwx------ 37 root root 2304 Mar 9 10:02 .. drwxr-xr-x 3 nobody users 72 Mar 9 10:03 a drwxr-xr-x 2 nobody users 48 Mar 9 10:03 b -rw-r--r-- 1 nobody users 0 Mar 9 10:03 foo
Moreover, there doesn't seem to be any way of invoking chown so that it operates recursively on a directory tree but ignores (doesn't follow) symbolic links.
</snip>
Discussion of this issue with Jim Meyering <[EMAIL PROTECTED]> and Paul Eggert <[EMAIL PROTECTED]> this morning considered a number of explanations:
-chown has a bug in coreutils 5.2.1 -there is something wrong with the kernel that affects the behavior of chown -there is something wrong with Suse 9.2 coreutils-5.2.1-32.rpm
I'm using the plain vanilla kernel 2.6.11.1 from kernel.org. I can reproduce the problem with this kernel and also with Suse kernel-default-2.6.8-24.11.rpm. I also note that "chmod" behaves as expected in contrast to "chown" (while they are both presumably based on the same libraries and kernel facilities).
Additionally, on the suggestion of Paul Eggert, I built ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz and tested the new chown on the same machine with kernel.org kernel 2.6.11.1. With this configuration, chown behaves correctly. The chown built from ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz also works correctly.
This is all good evidence that the kernel is not at fault. The problem also appears to be unique to the Suse rpm coreutils-5.2.1. I have not tested other Suse versions.
I then did:
rpmbuild --rebuild --target i686 coreutils-5.2.1-32.src.rpm rpm -Uhv --force /usr/src/packages/RPMS/i686/coreutils-5.2.1-32.i686.rpm
The problem still manifests itself, which seems to rule out a library incompatibility.
I have filed a bug about this with Suse, but I'm posting this update here as well since this issue means that running chown can have very serious unintended consequences.
Regards, Mark Brand
_______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils