Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 219900 - "cp -a" overwrites with a zero length file on NFS mount
"cp -a" overwrites with a zero length file on NFS mount
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
: 222259 280331 358701 (view as bug list)
Depends On:
Blocks: FC6Update
  Show dependency treegraph
Reported: 2006-12-15 21:29 EST by Paul Dickson
Modified: 2007-11-30 17:11 EST (History)
9 users (show)

See Also:
Fixed In Version: coreutils-5.97-12.6.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-12 06:16:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch fixing the problem (2.14 KB, patch)
2006-12-20 10:37 EST, Paul Dickson
no flags Details | Diff

  None (edit)
Description Paul Dickson 2006-12-15 21:29:58 EST
Description of problem:
I tried to backup a file with "cp -a toc toc~".  The toc~ already existed, and
the result was a zero length version of toc~.  This doesn't happen on my local
HD volumes.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ls -l >toc
2. cp -a toc toc~
3. ls -l toc*
4. cp -a toc toc~
5. ls -l toc*
Actual results:
-rw-rw-r-- 1 dickson dickson 256 Dec 15 19:12 toc
-rw-rw-r-- 1 dickson dickson   0 Dec 15  2006 toc~

Expected results:
-rw-rw-r-- 1 dickson dickson 256 Dec 15 19:12 toc
-rw-rw-r-- 1 dickson dickson 256 Dec 15 19:12 toc~

Additional info:
If I rm the destination first, the copy works.  It also works without the -a
Comment 1 Paul Dickson 2006-12-15 21:37:13 EST
It works OK from another system running kernel-2.6.18-1.2798.fc6 talking to the
same server (kernel-2.6.18-1.2708.fc6).
Comment 2 Paul Dickson 2006-12-18 23:12:33 EST
This still doesn't work under kernel-2.6.19-1.2877.fc7.
Comment 3 Paul Dickson 2006-12-18 23:44:53 EST
I just noticed that it works under, but not after according to
the changelog of the above kernels.
Comment 4 Paul Dickson 2006-12-19 12:37:13 EST
Comment #3 is apparently a false lead.  The problem goes away if I switch
SELinux from Permissive to Disabled.  The other machines are running with it
Comment 6 Paul Dickson 2006-12-20 10:37:26 EST
Created attachment 144111 [details]
Patch fixing the problem

This patch is from Trond Myklebust <trond.myklebust@fys.uio.no>.  I tested a
kernel I compiled from an SRPM to confirm the problem still occurred, then I
applied this patch and retested.  This patch fixes my problem.
Comment 7 Stephen Smalley 2007-01-29 08:29:02 EST
The kernel patch is wrong; it just hides the bug in cp.
Please reassign to coreutils.
Comment 8 Jim Meyering 2007-01-30 10:46:58 EST
Thanks for the info.
I have reproduced the problem.

I'm in the process of changing how the upstream version of cp -a works.
It will try to preserve context, and give a diagnostic for any failure,
but failure to preserve context will not change its exit status.
However, with "cp --preserve=context" or "cp --preserve=all", failure
to preserve context *will* make cp exit with nonzero status.

I'd like to add a test script to exercise this fix, but depending on
the existence of a writable, NFS-mounted partition is not a recipe for
good coverage.  Can anyone suggest an easier way to provoke fsetfilecon
failure on a file we've just opened (but not created -- it already existed)
for writing?

Here are the tests (run in an empty nfs-mounted directory, on a system with
e.g., SELINUX=permissive (not "disabled")):

Test1 (/bin/cp from coreutils-6.7-3.fc7 would fail this one)
  echo foo > f; cp f ff; cp -a f ff || fail=1
  test -s ff || fail=1
  test $fail = 0 || echo fail

  # Expect the latter cp to fail:
  echo foo > f; cp f ff; cp --preserve=context f ff && fail=1
  test $fail = 0 || echo fail
Comment 9 Daniel Walsh 2007-02-14 16:09:59 EST
*** Bug 222259 has been marked as a duplicate of this bug. ***
Comment 10 Jan Hutař 2007-10-29 15:36:41 EDT
I can see this also in F8:


# mount -t nfs4 localhost:/ /mnt/tmp/
# cd /mnt/tmp/
# echo "hello" > f
# cp f ff
# /bin/cp -a f ff
# cmp f ff && echo PASS
cmp: EOF on ff

# ls -Z f ff
-rw-r--r--  root root system_u:object_r:nfs_t:s0       f
-rw-r--r--  root root system_u:object_r:nfs_t:s0       ff
# ls -l f ff
-rw-r--r-- 1 root root 6 2007-10-29 20:31 f
-rw-r--r-- 1 root root 0 2007-10-29 20:31 ff

Hope this helps,
Comment 11 Ondrej Vasik 2007-10-30 05:51:19 EDT
I have the same report in #280331 (maybe a bit different- for SELinux) and for
RHEL5(#320771). Problem seems to be fixed in latest upstream snapshot - it
worked for me there. (http://meyering.net/cu/coreutils-6.9-ss.tar.gz) - I'm
trying to find out what has fixed this cp -a , you may use cp -dRpP with success
even with the current versions, so I hope it will be easy fix and will be
finished soon.
Comment 12 Daniel Walsh 2007-10-30 06:36:19 EDT
What avc is this generating?
Comment 13 Ondrej Vasik 2007-10-30 12:30:00 EDT
*** Bug 280331 has been marked as a duplicate of this bug. ***
Comment 14 Ondrej Vasik 2007-10-30 14:06:00 EDT
*** Bug 358701 has been marked as a duplicate of this bug. ***
Comment 15 Ondrej Vasik 2007-10-30 14:08:31 EDT
F-7 , F-8 and RAWHIDE packages for that bug are hopefully fixed. FC-6 one will
need some changes, will be built hopefully tomorrow.
Comment 16 Ondrej Vasik 2007-11-12 06:16:33 EST
coreutils-5.97-12.6.fc6 Testing update has been successfuly pushed for fc6 ,

Note You need to log in before you can comment on or make changes to this bug.