[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: chmod changing ctime even if no mode change
From: |
Ray Dillinger |
Subject: |
Re: chmod changing ctime even if no mode change |
Date: |
Sun, 13 Oct 2013 08:07:25 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 |
On 10/13/2013 05:43 AM, Bernhard Voelker wrote:
> I'm somehow tempted to read that as "but don't do it if nothing has
> changed". Fixing the code accordingly wouldn't be too hard ... _but_
> that would stand in contrast to commit f8e66794 [3] which (probably
> precautionarily?) did it the other way round back in 2000:
>
> Perform the chmod even if the
> file mode permission bits are the same as those that should be set.
> Omitting the chmod call would be alright with minimal 1003.1e DS17
> ACLs, but eventually there will be other permissions in addition to
> rwx. E.g., add and delete for directories, and something analogous
> to NT's take ownership permission.
>
> Does anyone know of a real situation where omitting the actual chmod(3)
> call would cause problems? Otherwise, I'd say that current chmod(1)
> violates POSIX.
> WDYT?
My opinion is that chmod should definitely update the file time if it
changes any permission or file attribute, and that on systems that
have permissions beyond rwx, or more than 3 'levels' of permissions,
that includes cases in which the changes did not include any of
the classic UNIX permission bits.
Conversely, if it changed _nothing_ about the file's permissions or
attributes, then it ought not update the timestamp either.
Bear