GNU bug report logs -
#29788
chown: recursive operation with "-H" flag does not work as documented
Previous Next
Reported by: Michael Orlitzky <michael <at> orlitzky.com>
Date: Wed, 20 Dec 2017 18:31:01 UTC
Severity: normal
Tags: notabug
Done: Bernhard Voelker <mail <at> bernhard-voelker.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 20 Dec 2017 21:58:57 +0100
with message-id <2b3abf4b-9529-482d-cc48-7c17c7d906bc <at> bernhard-voelker.de>
and subject line Re: bug#29788: chown: recursive operation with "-H" flag does not work as documented
has caused the debbugs.gnu.org bug report #29788,
regarding chown: recursive operation with "-H" flag does not work as documented
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
29788: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29788
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
The documentation for the "-H" flag to chown says,
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
This is not doing what I think it should do. In a terminal, as my "mjo"
system user, I can run,
$ mkdir foo
$ mkdir bar
$ ln -s ../bar foo/baz
$ sudo chown --verbose --recursive -H root foo
which outputs...
changed ownership of 'foo/baz' from mjo to root
changed ownership of 'foo' from mjo to root
However, the path "foo/baz" was not passed on the command-line, and
chown did in fact follow the symlink,
$ ls -l | grep bar
drwxr-xr-x 2 root mjo 4.0K 2017-12-20 13:19 bar
as evidenced by the fact that "bar" was created as mjo:mjo.
[Message part 3 (message/rfc822, inline)]
tag 29788 notabug
stop
On 12/20/2017 07:24 PM, Michael Orlitzky wrote:
> The documentation for the "-H" flag to chown says,
>
> 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
>
> This is not doing what I think it should do. In a terminal, as my "mjo"
> system user, I can run,
>
> $ mkdir foo
> $ mkdir bar
> $ ln -s ../bar foo/baz
> $ sudo chown --verbose --recursive -H root foo
>
> which outputs...
>
> changed ownership of 'foo/baz' from mjo to root
> changed ownership of 'foo' from mjo to root
>
> However, the path "foo/baz" was not passed on the command-line, and
> chown did in fact follow the symlink,
>
> $ ls -l | grep bar
> drwxr-xr-x 2 root mjo 4.0K 2017-12-20 13:19 bar
>
> as evidenced by the fact that "bar" was created as mjo:mjo.
I think there is something else going on you didn't consider:
--dereference affect the referent of each symbolic link (this is
the default), rather than the symbolic link itself
The -H option does not affect 'foo/baz' (or the target it references),
but only the command line arg 'foo'. So the test case for -H is:
$ mkdir bar bar/baz
$ ln -s bar foo
$ sudo chown --verbose --recursive -H root foo
changed ownership of 'foo/baz' from berny to root
changed ownership of 'foo' from berny to root
$ find . -ls
4014266 4 drwxr-xr-x 3 berny users 4096 Dec 20 21:50 .
4014269 4 drwxr-xr-x 3 root users 4096 Dec 20 21:50 ./bar
4014271 4 drwxr-xr-x 2 root users 4096 Dec 20 21:50 ./bar/baz
4014272 0 lrwxrwxrwx 1 berny users 3 Dec 20 21:50 ./foo -> bar
Without -H, chown would not dereference 'foo', and change the ownership of
the symlink (on systems which support this):
$ sudo chown --verbose --recursive root foo
changed ownership of 'foo' from berny to root
$ find . -ls
4014266 4 drwxr-xr-x 3 berny users 4096 Dec 20 21:51 .
4014269 4 drwxr-xr-x 3 berny users 4096 Dec 20 21:51 ./bar
4014271 4 drwxr-xr-x 2 berny users 4096 Dec 20 21:51 ./bar/baz
4014272 0 lrwxrwxrwx 1 root users 3 Dec 20 21:51 ./foo -> bar
Thus, I think this not a bug in chmod or the documentation, but in the
your expectations. Therefore, I'm marking this as not-a-bug in our bug
tracker. Of course, you are welcome to continue the discussion, and if
needed we can reopen this issue at a later point.
Have a nice day,
Berny
This bug report was last modified 7 years and 205 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.