Bug 219900 - "cp -a" overwrites with a zero length file on NFS mount
Summary: "cp -a" overwrites with a zero length file on NFS mount
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils   
(Show other bugs)
Version: 6
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact:
: 222259 280331 358701 (view as bug list)
Depends On:
Blocks: FC6Update
TreeView+ depends on / blocked
Reported: 2006-12-16 02:29 UTC by Paul Dickson
Modified: 2007-11-30 22:11 UTC (History)
9 users (show)

Fixed In Version: coreutils-5.97-12.6.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-12 11:16:33 UTC
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 15:37 UTC, Paul Dickson
no flags Details | Diff

Description Paul Dickson 2006-12-16 02:29:58 UTC
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-16 02:37:13 UTC
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-19 04:12:33 UTC
This still doesn't work under kernel-2.6.19-1.2877.fc7.

Comment 3 Paul Dickson 2006-12-19 04:44:53 UTC
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 17:37:13 UTC
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 15:37:26 UTC
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 13:29:02 UTC
The kernel patch is wrong; it just hides the bug in cp.
Please reassign to coreutils.

Comment 8 Jim Meyering 2007-01-30 15:46:58 UTC
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 21:09:59 UTC
*** Bug 222259 has been marked as a duplicate of this bug. ***

Comment 10 Jan Hutař 2007-10-29 19:36:41 UTC
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 09:51:19 UTC
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 10:36:19 UTC
What avc is this generating?

Comment 13 Ondrej Vasik 2007-10-30 16:30:00 UTC
*** Bug 280331 has been marked as a duplicate of this bug. ***

Comment 14 Ondrej Vasik 2007-10-30 18:06:00 UTC
*** Bug 358701 has been marked as a duplicate of this bug. ***

Comment 15 Ondrej Vasik 2007-10-30 18:08:31 UTC
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 11:16:33 UTC
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.