bug#50791: Recursive chmod exit status in coreutils-9.0

[Chris Webb]

Since bbb19b, chmod has started returning EXIT_FAILURE after skipping a
symlink during a recursive change. This affects chmod in the newly released
coreutils-9.0 vs the previous coreutils-8.32 and older versions:

  # mkdir t
  # cd t
  # : > foo
  # ln -s foo bar

  # chmod-8.32 -v -R u+r . ; echo "Exit status $?"
  mode of '.' retained as 0755 (rwxr-xr-x)
  neither symbolic link './bar' nor referent has been changed
  mode of './foo' retained as 0644 (rw-r--r--)
  Exit status 0

  # chmod-9.0 -v -R u+r . ; echo "Exit status $?"
  mode of '.' retained as 0755 (rwxr-xr-x)
  neither symbolic link './bar' nor referent has been changed
  mode of './foo' retained as 0644 (rw-r--r--)
  Exit status 1

The non-zero exit code is accompanied by no error message or diagnostic.

Success from process_file() in src/chmod.c is detected by

  ch.status >= CH_NO_CHANGE_REQUESTED

and the ordering for the possible outcomes in bbb19b puts CH_NOT_APPLIED in
the failure range. However, we finish with CH_NOT_APPLIED if and only if a
symlink has been (correctly) skipped.

I believe the simple reordering:

diff --git a/src/chmod.c b/src/chmod.c
index 37b04f500..36894854f 100644
--- a/src/chmod.c
+++ b/src/chmod.c
@@ -44,9 +44,9 @@ struct change_status
   enum
     {
       CH_NO_STAT,
-      CH_NOT_APPLIED,
       CH_FAILED,
       CH_NO_CHANGE_REQUESTED,
+      CH_NOT_APPLIED,
       CH_SUCCEEDED
     }
     status;

is sufficient to fix with no other side-effects.

Best wishes,
Chris.