Re: "cannot dereference" error from "chown -RH"

[enh]

On Fri, Jun 26, 2009 at 05:40, Jim Meyering<address@hidden> 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/