Re: "cannot dereference" error from "chown -RH"
On Fri, Jun 26, 2009 at 05:40, Jim Meyering wrote: > enh wrote: > >> if i create a dangling symbolic link within a tree, "chown -RH >> top-of-tree" gets me a "cannot dereference" error. >> >> STEPS TO REPRODUCE: >> >> cd /tmp >> mkdir chown-test >> cd chown-test >> ln -s poop parp >> cd .. >> chown -RH :nogroup chown-test > > Thanks for taking the time to report that. > However, I think you have a misunderstanding. > >> ACTUAL OUTPUT: >> >> chown: cannot dereference `chown-test/parp': No such file or directory >> chown: changing group of `chown-test': Operation not permitted >> >> EXPECTED BEHAVIOR: >> >> i don't think chown should try to dereference the dangling symbolic link. > > You're confusing the hierarchy-traversal options (-H, -L, -P, and whether > they dereference symlinks) and an independent option that determines, > once a file system object has been selected, whether chown should > operate on it or on whatever it references if it's a symlink. > > Maybe you didn't notice the description of the --dereference option? > > --dereference > affect the referent of each symbolic link (this is the > default), rather than the symbolic link itself > > -h, --no-dereference > affect each symbolic link instead of any referenced file > (useful only on systems that can change the ownership of a > symlink) > >> looking at the source, i think affect_symlink_referent should be >> false. i think the code in chown.c's main() should be more like the >> code in chcon.c's main(), but that both should be changed to test >> (bit_flags & FTS_PHYSICAL) rather than (bit_flags == FTS_PHYSICAL), >> because -H sets bit_flags to FTS_COMFOLLOW | FTS_PHYSICAL. >> >> alternatively, i could have completely misunderstood the intended >> behavior of -RH. but it seems to me like -H should cause only symbolic >> links explicitly named on the command-line to be dereferenced. > > This is described in the "info" documentation, > i.e., what you get when you run "info coreutils chown". > If that's not clear enough, specific suggestions for improvement > are most welcome. > > It cross-references this section: > > 2.9 Traversing symlinks > === > > The following options modify how `chown' and `chgrp' traverse a > hierarchy when the `--recursive' (`-R') option is also specified. If > more than one of the following options is specified, only the final one > takes effect. These options specify whether processing a symbolic link > to a directory entails operating on just the symbolic link or on all > files in the hierarchy rooted at that directory. > > These options are independent of `--dereference' and > `--no-dereference' (`-h'), which control whether to modify a symlink or > its referent. i think this paragraph, had it been in the man page, would have prevented my confusion. putting -H, -L, and -P next to --dereference and --no-dereference (as with -h on the Mac OS man page) _might_ have helped, but your "these are traversal, those are reference" paragraph would have been perfect. thanks! now all i need to do is cope with ancient versions of GNU chown that don't support -RH in conjunction with -h... ;-) --elliott > `-H' > If `--recursive' (`-R') is specified and a command line argument > is a symbolic link to a directory, traverse it. > > `-L' > In a recursive traversal, traverse every symbolic link to a > directory that is encountered. > > `-P' > Do not traverse any symbolic links. This is the default if none > of `-H', `-L', or `-P' is specified. > -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: "cannot dereference" error from "chown -RH"
enh wrote: > if i create a dangling symbolic link within a tree, "chown -RH > top-of-tree" gets me a "cannot dereference" error. > > STEPS TO REPRODUCE: > > cd /tmp > mkdir chown-test > cd chown-test > ln -s poop parp > cd .. > chown -RH :nogroup chown-test Thanks for taking the time to report that. However, I think you have a misunderstanding. > ACTUAL OUTPUT: > > chown: cannot dereference `chown-test/parp': No such file or directory > chown: changing group of `chown-test': Operation not permitted > > EXPECTED BEHAVIOR: > > i don't think chown should try to dereference the dangling symbolic link. You're confusing the hierarchy-traversal options (-H, -L, -P, and whether they dereference symlinks) and an independent option that determines, once a file system object has been selected, whether chown should operate on it or on whatever it references if it's a symlink. Maybe you didn't notice the description of the --dereference option? --dereference affect the referent of each symbolic link (this is the default), rather than the symbolic link itself -h, --no-dereference affect each symbolic link instead of any referenced file (useful only on systems that can change the ownership of a symlink) > looking at the source, i think affect_symlink_referent should be > false. i think the code in chown.c's main() should be more like the > code in chcon.c's main(), but that both should be changed to test > (bit_flags & FTS_PHYSICAL) rather than (bit_flags == FTS_PHYSICAL), > because -H sets bit_flags to FTS_COMFOLLOW | FTS_PHYSICAL. > > alternatively, i could have completely misunderstood the intended > behavior of -RH. but it seems to me like -H should cause only symbolic > links explicitly named on the command-line to be dereferenced. This is described in the "info" documentation, i.e., what you get when you run "info coreutils chown". If that's not clear enough, specific suggestions for improvement are most welcome. It cross-references this section: 2.9 Traversing symlinks === The following options modify how `chown' and `chgrp' traverse a hierarchy when the `--recursive' (`-R') option is also specified. If more than one of the following options is specified, only the final one takes effect. These options specify whether processing a symbolic link to a directory entails operating on just the symbolic link or on all files in the hierarchy rooted at that directory. These options are independent of `--dereference' and `--no-dereference' (`-h'), which control whether to modify a symlink or its referent. `-H' If `--recursive' (`-R') is specified and a command line argument is a symbolic link to a directory, traverse it. `-L' In a recursive traversal, traverse every symbolic link to a directory that is encountered. `-P' Do not traverse any symbolic links. This is the default if none of `-H', `-L', or `-P' is specified. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
"cannot dereference" error from "chown -RH"
if i create a dangling symbolic link within a tree, "chown -RH top-of-tree" gets me a "cannot dereference" error. STEPS TO REPRODUCE: cd /tmp mkdir chown-test cd chown-test ln -s poop parp cd .. chown -RH :nogroup chown-test ACTUAL OUTPUT: chown: cannot dereference `chown-test/parp': No such file or directory chown: changing group of `chown-test': Operation not permitted EXPECTED BEHAVIOR: i don't think chown should try to dereference the dangling symbolic link. looking at the source, i think affect_symlink_referent should be false. i think the code in chown.c's main() should be more like the code in chcon.c's main(), but that both should be changed to test (bit_flags & FTS_PHYSICAL) rather than (bit_flags == FTS_PHYSICAL), because -H sets bit_flags to FTS_COMFOLLOW | FTS_PHYSICAL. alternatively, i could have completely misunderstood the intended behavior of -RH. but it seems to me like -H should cause only symbolic links explicitly named on the command-line to be dereferenced. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
