FYI: avoid strange new test failure

[Jim Meyering]

buildbot reported a coreutils test failure in a new test, e.g.,

  http://buildbot.proulx.com:9000/i686%20gnu-linux%20full/builds/371/step-test/0

  make  check-TESTS
  make[3]: Entering directory 
`/usr/local/build/coreutils/build-i686-gnu-linux-full/build/project/build/tests/cp'
  make[4]: Entering directory 
`/usr/local/build/coreutils/build-i686-gnu-linux-full/build/project/build/tests/cp'
  FAIL: parent-perm.log

At first I thought it was my fault, i.e., a bug in the test,
due to not handling the sticky dir. bit.
And I suppose technically it is, but...

I reproduced the problem:
Starting in a directory with the sticky bit set,
create a directory and show it inherits the sticky bit:
  $ mkdir a
  $ ls -ld a
  drwxr-sr-x 2 buildbot build 4096 2008-01-08 06:35 a

Try to copy that empty dir, with all its attributes to a new name:
  $ strace cp -a a b
  ...
  chmod("b", 042755)                      = 0
  close(0)                                = 0
  close(1)                                = 0
  close(2)                                = 0
  exit_group(0)                           = ?
  Process 20618 detached

Show that the sticky attribute has been lost:
  $ ls -ld b
  drwxr-xr-x 2 buildbot build 4096 2008-01-08 06:35 b

Try to apply it manually:
  $ strace chmod g+s b
  ...
  chmod("b", 02755)                       = 0
  fchdir(3)                               = 0
  close(3)                                = 0
  close(1)                                = 0
  exit_group(0)                           = ?
  Process 14188 detached

That doesn't work either.  And still no failure.
  $ ls -ld b
  drwxr-xr-x 2 buildbot build 4096 2008-01-08 06:35 b
  $ ls -ld a
  drwxr-sr-x 2 buildbot build 4096 2008-01-08 06:35 a

Notice that this user is not a member of the group, "build":
  $ id -a
  uid=105(buildbot) gid=65534(nogroup) groups=65534(nogroup)

Confirm that it's due to the way the underlying chmod syscall works:
  $ perl -e 'chmod 02755, "b" or die'
  $ ls -ld b
  drwxr-xr-x 2 buildbot build 4096 2008-01-08 06:35 b

Yep, in this case, the S_ISGID bit is ignored.
And this behavior is even allowed by POSIX, though the
exclusion loophole there is big enough to drive a truck through.

The Linux "man 3 chmod" page says essentially the same thing:

       Additional  implementation-defined  restrictions  may cause the S_ISUID
       and S_ISGID bits in mode to be ignored.

So I've changed the test to accommodate this ugliness:

2008-01-08  Jim Meyering  <address@hidden>

        parent-perm: avoid a bizarre test failure.
        * tests/cp/parent-perm: Accommodate the situation in which
        chmod ("dir", 02755) returns 0 yet fails to set the S_ISGID bit.

diff --git a/tests/cp/parent-perm b/tests/cp/parent-perm
index 1c7a222..cedcac4 100755
--- a/tests/cp/parent-perm
+++ b/tests/cp/parent-perm
@@ -33,6 +33,15 @@ cp -p --parent a/b/d/foo e || fail=1

 # Ensure that permissions on just-created directory, e/a/,
 # are the same as those on original, a/.
-test $(stat --printf %A a) = $(stat --printf %A e/a) || fail=1
+
+# The sed filter maps any 's' from an inherited set-GID bit
+# to the usual 'x'.  Otherwise, under unusual circumstances, this
+# test would fail with e.g., drwxr-sr-x != drwxr-xr-x .
+# For reference, the unusual circumstances is: build dir is set-gid,
+# so "a/" inherits that.  However, when the user does not belong to
+# the group of the build directory, chmod ("a/e", 02755) returns 0,
+# yet fails to set the S_ISGID bit.
+test $(stat --printf %A a|sed s/s/x/g) = $(stat --printf %A e/a|sed s/s/x/g) ||
+  fail=1

 (exit $fail); exit $fail
--
1.5.4.rc2.61.g6ed4e