cp giving "Operation not applicable" on newer solaris

[Pádraig Brady]

Testing on "SunOS 5.10 Generic_150400-17 sun4v sparc" on tmpfs,
all tests pass except for `cp -a` returning an error copying ACLs.
The diagnostic is for ENOSYS, and glancing at the gnulib code
suggests it should fall back to chmod on ENOSYS, rather than failing...

`mkdir x && truss cp -a x y` gives:

acl("x", ACE_GETACLCNT, 0, 0x00000000)          = 3
acl("x", ACE_GETACL, 3, 0x00040050)             = 3
acl("x", GETACLCNT, 0, 0x00000000)              = 4
acl("x", GETACL, 4, 0x00040080)                 = 4
acl("y", SETACL, 4, 0x00040080)                 Err#89 ENOSYS
acl("y", ACE_SETACL, 3, 0x00040050)             Err#89 ENOSYS
acl("y", ACE_GETACL, 333, 0xFFBFE148)           = 3
acl("y", ACE_SETACL, 6, 0xFFBFE100)             Err#89 ENOSYS


Digging a little for the ACL entry causing the fallback to chmod
to not suffice, shows that it's the NEW_ACE_DELETE_CHILD bit
that's causing the issue. The following tentative patch
avoids checking that bit, and thus the diagnostic and EXIT_FAILURE:

diff --git a/lib/acl-internal.c b/lib/acl-internal.c
index 4de60c3..e56d28f 100644
--- a/lib/acl-internal.c
+++ b/lib/acl-internal.c
@@ -252,7 +252,8 @@ acl_ace_nontrivial (int count, ace_t *entries)
       access_masks[1] &= ~(NEW_ACE_WRITE_NAMED_ATTRS
                            | NEW_ACE_WRITE_ATTRIBUTES
                            | NEW_ACE_WRITE_ACL
-                           | NEW_ACE_WRITE_OWNER);
+                           | NEW_ACE_WRITE_OWNER
+                           | NEW_ACE_DELETE_CHILD);
       if ((NEW_ACE_READ_NAMED_ATTRS
            | NEW_ACE_READ_ATTRIBUTES
            | NEW_ACE_READ_ACL

So we can we read this bit but not set it?
That seems like it might be a bug in solaris?

Note the 'delete_child' bit is not mentioned in the source dir?
but that's probably a limitation of the ls version on this system:
  > ls -lvd x
  drwxr-xr-x   2 padraig  csw          117 Nov 26 19:05 x
       0:user::rwx
       1:group::r-x               #effective:r-x
       2:mask:rwx
       3:other:r-x

I see Bruno/Jim noticed issues with this "delete_child" bit previously:
https://lists.gnu.org/archive/html/coreutils/2011-09/msg00065.html

Looking at richacls on Linux I see that "delete_child"
is implicit with the write bit:
  $ getrichacl --long .
  .:
      
owner@:list_directory/add_file/add_subdirectory/execute/delete_child::allow
   everyone@:execute::allow

That suggests my patch above might be an acceptable workaround?

cheers,
Pádraig.