Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary

[Erik Rossen]

On Tue, Sep 02, 2008 at 08:06:51PM +0200, Jim Meyering wrote:
> Good idea.
> At least for chmod, it is not only possible, but the optimization
> would be essentially free, since chmod already has the required stat data.

Yeah, I thought it was a good idea too.

> AFAICS POSIX
> (http://www.opengroup.org/onlinepubs/007908775/xsh/chmod.html)
> allows the behavior you propose.  That same feature was even
> requested a few years ago, but no one implemented it.

Thanks for the lead - I had no idea where to go looking for POSIX specs.
But you got the wrong URL.  The URL above refers to chmod() the
function.  What we needed was chmod the utility.  Here it is:

        http://www.opengroup.org/onlinepubs/007908799/xcu/chmod.html

And, if one wants to be REALLY pedantic, it looks like the file node is
supposed to be changed each time.  For example, here is an extract:

        +
            If perm is not specified, the + operation will not change
            the file mode bits. If who is not specified, the file mode
            bits represented by perm for the owner, group and other
            permissions, except for those with corresponding bits in the
            file mode creation mask of the invoking process, will be
            set. Otherwise, the file mode bits represented by the
            specified who and perm values will be set.

Here it says that the bits will be set.  Unfortunately, they do not say
something like "set unless already set".  If the feature is to added, it
will be a non-standard option.

> A patch would be welcome.

I totally agree.

> If you're not interested, let me know in any case and
> I'll add it to the TODO list.

I think I will let you add it to the TODO list. :-)

> For chgrp (probably chown, too, at least in some cases), it's not
> as obvious, since the current implementation does not stat files
> before changing permissions.  So, to do what you want would involve
> adding a stat call per file to get owner/group in order to avoid(maybe)
> the offending ownership-changing syscall.  That would not be an
> improvement.

As far as speed is concerned, you are right that an extra stat() would
usually not improve matters.  (Would it be an enormous penalty?  I doubt
it.)  But users of file integrity checking systems like myself will be
grateful for the change of behavior.

-- 
Erik Rossen                               OpenPGP key: 2935D0B9
address@hidden                          If you do not know what
http://people.linux-gull.ch/rossen        to do, start with RTFM.