bug#21062: coreutils-8.24 - cp(1) check failures on tmpfs filesystem (Solaris 10 / Solaris 11)

[Pádraig Brady]

On 15/07/15 12:04, Peter Bray wrote:
> Greetings,
> 
> While building coreutils-8.24 on Sun Solaris 10 Update 8, Oracle
> Solaris 10 Update 11 and Oracle Solaris 11.2, I noticed the "gmake
> check" on Solaris 10 Update 11 and Solaris 11.2 systems would give (at
> least) FAIL: 7 and ERROR: 1 in the final summary, as the following
> command shows:
> 
>    egrep '(FAIL|ERROR):' ./tests/test-suite.log
> 
> # XFAIL: 0
> # FAIL:  7
> # ERROR: 1
> FAIL: tests/cp/backup-dir
> FAIL: tests/cp/cp-parents
> FAIL: tests/cp/duplicate-sources
> ERROR: tests/cp/parent-perm
> FAIL: tests/cp/parent-perm-race
> FAIL: tests/cp/preserve-link
> FAIL: tests/cp/reflink-perm
> FAIL: tests/cp/src-base-dot
> 
> These errors did not happen on Sun Solaris 10 Update 8 VMs.
> 
> Investigating further showed a common error message "Operation not 
> applicable"
> 
>    grep "Operation not applicable" ./tests/test-suite.log
> 
> cp: preserving permissions for 'y/x': Operation not applicable
> cp: preserving permissions for 'y/x': Operation not applicable
> cp: preserving permissions for 'e/d/a/b/c': Operation not applicable
> cp: preserving permissions for 'e/d/a/b': Operation not applicable
> cp: preserving permissions for 'g/sym/b/c': Operation not applicable
> cp: preserving permissions for 'g/sym/b': Operation not applicable
> +cp: preserving permissions for 'dest/a': Operation not applicable
> +cp: preserving permissions for 'dest/a': Operation not applicable
> +cp: preserving permissions for 'dest/al': Operation not applicable
> cp: preserving permissions for 'e/a/b/c': Operation not applicable
> cp: preserving permissions for 'd/mode/fifo': Operation not applicable
> cp: preserving permissions for 'd/mode': Operation not applicable
> cp: preserving permissions for 't/s': Operation not applicable
> cp: preserving permissions for 't/s': Operation not applicable
> cp: preserving permissions for 'copy': Operation not applicable
> +cp: preserving permissions for './.': Operation not applicable
> 
> These builds all were conducted on a subdirectory of /tmp, which is a
> "tmpfs" filesystem by default on Solaris.  On a hunch, I rebuilt the
> code on a non-tmpfs filesystem (/var/tmp which on these systems is a
> sub-directory of the /var ZFS filesystem) and the problems did not
> appear.
> 
> Thus it would _appear_ that later Solaris 10 releases and Solaris 11
> have code which returns an error that may not have been detected in
> the Solaris 10 Update 8 release, for certain actions on a tmpfs
> filesystem. But that is purely a guess.
> 
> I have included complete "test-suite.log" from Solaris 10 Update 11 /
> GCC 4.9.3 (64-bit) build based in /tmp/64-bit/coreutils-8.24/. I have
> not investigated which of the three "preserving permissions for"
> instances in the code is the cause.
> 
>     grep -n "preserving permissions for" lib/* src/*
> 
> lib/copy-acl.c:54:      error (0, errno, _("preserving permissions for 
> %s"), quote (dst_name));
> src/copy.c:1377:          error (0, errno, _("preserving permissions for 
> %s"),
> src/copy.c:2844:              error (0, errno, _("preserving permissions 
> for %s"),
> 
> I'm guessing the next step would be narrowing down the failures to one
> or more locations in the code, but I'm yet to fully explore what the
> test harnesses are doing and which code blocks they are provoking.
> 
> As it late I'm just going to submit this so others can ponder it.
> 
> But I see a few possibilities once the source of the issue is known.
> 
>    - document that certain filesystem types do not support certain
>      command line options on some operating systems. Additionally,
>      place a note in the README for those systems, there are currently
>      no notes for Solaris.
> 
>    - take an alternate approach for "preserving permissions" on certain
>      filesystem types (I'm guessing here)

There was refactoring work done in this area in gnulib recently.
I noticed a very similar problem on FreeBSD and fixed it with:
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=716083c1

I suspect there is a similar unhandled case for Solaris.

thanks,
Pádraig.