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): kernel-2.6.18-1.2849.fc6 How reproducible: Always 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 argument.
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).
This still doesn't work under kernel-2.6.19-1.2877.fc7.
I just noticed that it works under 2.6.18.1, but not after 2.6.18.2 according to the changelog of the above kernels.
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 disabled.
Created attachment 144111 [details] Patch fixing the problem This patch is from Trond Myklebust <trond.myklebust.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.
The kernel patch is wrong; it just hides the bug in cp. Please reassign to coreutils.
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) fail=0 echo foo > f; cp f ff; cp -a f ff || fail=1 test -s ff || fail=1 test $fail = 0 || echo fail Test2 fail=0 # Expect the latter cp to fail: echo foo > f; cp f ff; cp --preserve=context f ff && fail=1 test $fail = 0 || echo fail
*** Bug 222259 has been marked as a duplicate of this bug. ***
Hello, I can see this also in F8: coreutils-6.9-6.fc8 kernel-2.6.23.1-37.fc8 nfs-utils-1.1.0-6.fc8 # 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, Jan
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.
What avc is this generating?
*** Bug 280331 has been marked as a duplicate of this bug. ***
*** Bug 358701 has been marked as a duplicate of this bug. ***
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.
coreutils-5.97-12.6.fc6 Testing update has been successfuly pushed for fc6 , closing.