[Top][All Lists]

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

chmod changing ctime even if no mode change

From: Bernhard Voelker
Subject: chmod changing ctime even if no mode change
Date: Sun, 13 Oct 2013 14:43:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

In a new openSUSE bug [1], a user complains that chmod changes a
file's change status timestamp although chmod did not have to change
any of the permission bits, e.g.

  $ touch test
  $ chmod 700 test
  $ stat test
  $ chmod 700 test
  $ stat test

The effect for the user is that backup/restore takes much longer
as backups are also triggered although it would not be necessary.
(They use a cron job for "fixing" the permissions in a shared

Apart from that, POSIX [2] says:

  Upon successfully changing the file mode bits of a file, the chmod
  utility shall mark for update the last file status change timestamp
  of the file.

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.


[1] openSUSE bug:

[2] POSIX spec:

[3] commit f8e66794:

Have a nice day,

reply via email to

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