GNU bug report logs -
#79130
Change/feature requests chcon/chgrp/chmod/chown/touch
Previous Next
Full log
View this message in rfc822 format
On 30/07/2025 09:05, Martin D Kealey wrote:
> I would like the 'chown -h' and 'chcon -h' to work the same way as
> 'touch -h': as well as not following symlinks for targets, they should also
> not follow a symlink given as --reference=.
For consistency it probably makes sense for `chmod -h` to also
not follow a symlink given as --reference=.
I know mode bits are less supported on symlinks on various systems,
but for consistency it probably makes sense.
Note -h, -HLP was added to chmod(1) only recently:
https://github.com/coreutils/coreutils/commit/07a69fc3b
I just didn't consider --reference behavior when implementing that.
> I know these would be incompatible changes, but to me this would seem more
> obvious, useful and consistent. What was the rationale for the existing
> behaviour, given that the POSIX specs for these commands lack any
> discussion of symlinks (and mostly they lack '-h' entirely)?
POSIX ch{own,mod}(1) also lack --reference, so we're more flexible in how
we treat these GNU extensions. As for why these always deref --reference I don't know.
For chown(1), --reference did come after -h, so I suspect it was just not considered.
Then chcon(1) and chmod(1) just copied what chown(1) was doing.
> An alternative (or additional) approach would be to add new explicit
> options (such as '--symlink-reference' and '--follow-reference') to all of
> the inode metadata manipulation commands including 'chcon', 'chgrp',
> 'chmod', 'chown', & 'touch'.
That would only be needed if mixing metadata between symlinks
and non symlinks, which I don't see as that useful.
>
> I'm willing to provide patches for either or both of these approaches.
> (Whatever changes are made to 'chown', the corresponding changes would be
> made to 'chgrp'.)
>
> Stepping back, I'm wondered about regularising the options available to all
> the file manipulation commands, so 'touch' would gain '-R', '-H', '-L', &
> '-P', and 'chmod' would gain '-h', '-H', '-L', & '-P' (functionality
> subject to whether the underlying FS supports
> fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding long
> options.
chmod(1) got those options in coreutils 9.5 as mentioned above.
That was because it already had the -R option.
It's best to avoid adding -R functionality to commands in general, so I'd leave touch as is
> Secondly, I note that 'touch -r' copies the atime and mtime separately; it
> would be nice to be able to have --atime= and --mtime= as separate options,
> as an alternative to both combined as --time=.
> Again, I can provide a patch if this would be acceptable.
I don't understand this request.
Is it just an interface change to existing functionality?
If so that wouldn't be warranted IMHO.
thanks,
Padraig.
This bug report was last modified 15 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.