GNU bug report logs - #21062
solaris: cp(1) check failures on tmpfs filesystem (Solaris 10 / Solaris 11)

Previous Next

To reply to this bug, email your comments to 21062 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Bray <pdb_ml <at> yahoo.com.au>
To: bug-coreutils <at> gnu.org
Subject: coreutils-8.24 - cp(1) check failures on tmpfs filesystem (Solaris
 10 / Solaris 11)
Date: Wed, 15 Jul 2015 21:04:27 +1000

[Message part 1 (text/plain, inline)]

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)

Regards,

Peter Bray
Sydney, Australia

[test-suite.log (text/plain, attachment)]

Message #8 received at 21062 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Peter Bray <pdb_ml <at> yahoo.com.au>, 21062 <at> debbugs.gnu.org, 
 Andreas Gruenbacher <andreas.gruenbacher <at> gmail.com>
Subject: Re: bug#21062: coreutils-8.24 - cp(1) check failures on tmpfs
 filesystem (Solaris 10 / Solaris 11)
Date: Wed, 15 Jul 2015 12:23:26 +0100

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.

Message #11 received at 21062 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
To: Peter Bray <pdb_ml <at> yahoo.com.au>
Cc: Pádraig Brady <P <at> draigbrady.com>, 21062 <at> debbugs.gnu.org
Subject: Re: bug#21062: coreutils-8.24 - cp(1) check failures on tmpfs
 filesystem (Solaris 10 / Solaris 11)
Date: Wed, 15 Jul 2015 17:49:28 +0200

Peter,

2015-07-15 13:23 GMT+02:00 Pádraig Brady <P <at> draigbrady.com>:
> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.