chmod changing ctime even if no mode change

[Bernhard Voelker]

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