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.
