[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even whe
Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
Mon, 15 Sep 2008 11:22:41 +0200
On Tue, Sep 02, 2008 at 10:48:30AM -0400, Michael Stone wrote:
> On Tue, Sep 02, 2008 at 03:50:16PM +0200, Erik Rossen wrote:
> >But it would be so much more elegant if chmod just Did The Right Thing.
> It's certainly arguable whether adding another non-standard flag is the
> Right Thing when it's fairly trivial to get the result in a more
> portable fashion using find(1).
It seems that the FreeBSD people think that making a change to the
filesystem only when necessary is The Right Thing. But I guess that
argument carries no weight in GNU. ;-)
> >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.
> Upstream monitors the debian bug logs and will presumably chime in if
> interested. I vaguely recall that people want these utilities to act
> even if not strictly necessary because of possible side effects for
> extended attributes.
> Mike Stone
I took your advice (paraphrased: "try another tool") and I now have
three options for fixing file permissions without disturbing the file
system too much:
1. find + chmod : classic but ugly
2. cfengine : Does The Right Thing, but difficult to do as a one-liner
unless you are already using cfengine for other stuff
3. setfacl -R : nice. Does The Right Thing as a fairly simple one-liner
setfacl is kind of interesting. Even if the filesystem is mounted
without extended ACLs enabled, it works for setting the POSIX ACLs and
it Does The Right Thing. For example, I can do
setfacl -R -m u::rwX,g::rwX,o:rX shares/
to fix every file and directory in "shares" to be readable, and writable
only by the owner and group of shares. And if I run the same command
again, stat shows that the ctime has not changed unless it was necessary
to modify the permissions of a file or directory.
I am pretty happy about this solution and I intend to use it in cases
where there is a integrity-checker in place and no cfengine.
But while doing my tests, I noticed something strange about setfacl: if
the filesystem is mounted with extended ACLs enabled (on a ext3 fs), it
is possible to use setfacl to make changes to file permissions and CTIME
IS NEVER MODIFIED EVEN IF PERMISSIONS ARE MODIFIED. I thought that this
was supposed to be impossible, but perhaps this is a known side-effect
("feature") of activating extended ACLs on ext3.
Can anyone else confirm this? I am running etch with an ext3 filesystem
that was created in June 2008. This is my "uname -a":
Linux mango 2.6.18-6-vserver-686 #1 SMP Mon Aug 18 11:11:15 UTC 2008
Erik Rossen OpenPGP key: 2935D0B9
address@hidden On fonce la tête dans
http://www.rtfm-sarl.ch le guidon et on RTFM.
|[Prev in Thread]
||[Next in Thread]|
- Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary,
Erik Rossen <=