[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21062: coreutils-8.24 - cp(1) check failures on tmpfs filesystem (So
From: |
Pádraig Brady |
Subject: |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
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.