bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch

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.