bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even wh


From: Jim Meyering
Subject: Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
Date: Tue, 02 Sep 2008 20:06:51 +0200

Erik Rossen <address@hidden> wrote:
> On Tue, Sep 02, 2008 at 08:19:38AM -0400, Michael Stone wrote:
>> On Tue, Sep 02, 2008 at 11:30:46AM +0200, you wrote:
>> >It would be nice if chmod (and chown and chgrp) only made changes to
>> >inodes when necessary so as not to change the ctime of files.
>>
>> I'm fairly certain there have also been complaints about these utilities
>> not resetting the inode even when not necessary.
>
> That is certainly possible, if that is normal POSIX behavior.
>
>> I'd suggest using them in conjunction with find(1) if you only want to
>> modify files that don't match a particular setting.
>
> Yup.
>
> But it would be so much more elegant if chmod just Did The Right Thing.
>
> Can I ask you to pass along this wishlist item to upstream and maybe ask
> them why ctime must be modified even when the permissions are not?  I
> would really like to know why.

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.

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.

A patch would be welcome.
If you're not interested, let me know in any case and
I'll add it to the TODO list.

If you are interested in writing the patch,
please follow the guidelines outlined here:
  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=HACKING;hb=HEAD

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]