GNU bug report logs - #79130
Change/feature requests chcon/chgrp/chmod/chown/touch

Previous Next

Full log

Message #20 received at 79130 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Martin D Kealey <martin <at> kurahaupo.gen.nz>
Cc: 79130 <at> debbugs.gnu.org
Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch
Date: Sat, 2 Aug 2025 14:06:21 +0100

On 02/08/2025 10:43, Martin D Kealey wrote:
> On Thu, 31 Jul 2025 at 07:51, Pádraig Brady <P <at> draigbrady.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.