On 10/13/2013 01:43 PM, Bernhard Voelker wrote: > 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
This is a tricky one, previously discussed at: http://lists.gnu.org/archive/html/bug-coreutils/2010-01/msg00303.html Pádraig.
