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

On 02/08/2025 10:43, Martin D Kealey wrote:
> On Thu, 31 Jul 2025 at 07:51, Pádraig Brady <[email protected]> wrote:
> 
>> 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.
>>
> [and I wrote]
> 
>>> (functionality subject to whether the underlying FS supports
>> fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod),
>>
> 
> Funny you should mention that; it's already in my patch set (wrapped in
> #ifdef CAN_CHMOD_SYMLINK).

It would be best to not vary the user interface defaults
based on system features.But yes, it would be good to keep ch{mod,own,con} interfaces in sync.

>> 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 don't mean that those options would *only* take symlinks, rather that
> they would be guaranteed to follow or not follow one if it happened to be
> provided.
> 
> On the whole I prefer the suggestion to have
> --no-dereference=[none|src|dest|all] except for the unnecessary negative.
> I suggest «--derefence=[n[one]|s[rc]|d[est]|a[ll]]»

I agree --dererence=... would be best if implementing from scratch.
But given the existing --no-dereference, I would just extend that.

> and the corresponding
> version «-D[n|s|d|a]», with --no-dereference being a synonym for
> «--dereference=none»/«-Dn» or «--dereference=src»/«-Ds» whichever matches
> «-h» behaviour in each command.
> 
> (I'll grant that «-D*mode*» is a bit clunky, but it avoids a profusion of
> new single-letter options, and I've often wished that cp, mv, ln, etc had
> «-B*mode*» (corresponding to «--backup=*mode*», rather than just «-b».)

Interesting interface, but again I'm not sure another short option is warranted here,
especially a short option taking an argument.

> I had also been pondering adding --ref-prefix= where each target file would
> obtain its reference from the corresponding file in another tree, which
> would only really be useful with --recurse. (Doing that with internal
> recursion would be a *lot* faster than, say «find . -type f -exec touch -h
> --ref=/other/path/{} {} \;» since that needs a separate invocation of
> «touch» for every target file.

Interesting. Though if only a performance benefit
as opposed to functionality benefit, it's less warranted.

That reminds me of the --pairs0-from suggestion at:
https://lists.gnu.org/archive/html/coreutils/2024-08/msg00019.html

> In the same bucket of regularisation: every inode metadata command uses
> «-c» to mean "verbose but only if it changes", EXCEPT «touch», where it's
> "don't create". I don't suppose we could have a uniform
> «--verbose=ifchanged»?

Interesting. Though touch doesn't have any --verbose option yet,
so I'm not convinced there is a pressing need for that?
>> 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.
>>
> 
> Currently it takes two invocations of ‘touch’ to change the atime and mtime
> to different values, UNLESS you're using -r in which case just one
> invocation will suffice: touch -r copies the reference's mtime onto the
> target's mtime, and the reference's atime onto the target's atime.
> 
> The idea would be to be able to perform this using explicit values for
> atime and mtime separately rather than using a reference file.
Ah right. Given that's not often needed, and a perf only change,I'm not sure that's warranted.

Thanks for taking the time to consider the touch interface so carefully.

cheers,
Padraig