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

From: Andreas Grünbacher <[email-masked]>
Date: Wed, 15 Jul 2015 17:49:28 +0200

Peter,

2015-07-15 13:23 GMT+02:00 Pádraig Brady <[email-masked]>:
> 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"

That's the ENOSYS error code on Solaris.

I cannot reproduce this here because I don't have access to different
versions of Solaris. it would be interesting to see which particular
command fails with which options, and in particular, which are the
failing system calls. The tool for system call tracing on Solari sis
called "truss".

>> 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.

I can likely guess from the failing system calls.

>> 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)

We should be able to just make it work.

Thanks,
Andreas