[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
directory).
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.
WDYT?
[1] openSUSE bug:
https://bugzilla.novell.com/show_bug.cgi?id=845245
[2] POSIX spec:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html
[3] commit f8e66794:
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=f8e66794
Have a nice day,
Berny
- chmod changing ctime even if no mode change,
Bernhard Voelker <=