Description of problem: cp -a and cp -dpR do NOT function the same as indicated by the documentation. cp -a will wipe out the destination file if it already exists and replace it with a file of size 0 on an NFS mounted file system while cp -dpR does not. This problem was reproduced 100% of the time on my computer (RHEL5 with latest patches) on an NFS mounted file system but did not occur on a locally mounted file system. This problem is not reproduced on a RHEL4 system writing to an NFS file system. The NFS file system was mounted with the following options: IP#:/nfs/backup /nfs/backup nfs rsize=8192,wsize=8192,exec,hard,rw,bg 0 0 ALL of my backups are corrupted as a result of using cp -uav to run backup scripts. This is really easy to reproduce once I noticed it. cp -a filename /nfs_filesystem/filename File is copied correctly if filename does not exist. Execute the command again. cp -a filename /nfs_filesystem/filename Destination filename is replaced with file of size 0. On the other hand, using cp -dpR in the above example copies the file correctly in both cases. If asked to overwrite the file answer y - it doesn't seem to affect the results. Unmounting and remounting the nfs file system did not affect the behaviour. Version-Release number of selected component (if applicable): coreutils-5.97-12.1.el5 How reproducible: Every time on my machine Steps to Reproduce: 1. cp -a filename /nfs_filesystem/filename 2. ls -l /nfs_filesytem/filename (if first copy file looks ok) 3. cp -a filename /nfs_filesystem/filename 4. ls -l /nfs_filesytem/filename (destination filename now has size 0) Actual results: Copied file is corrupted/gone - size is zero. Expected results: Copied file should be intact. Additional info: I don't know what might be relevant. My system software specs are in RHN. The source filesystem is on a logical volume running under a RAID1 configuration. The destination filesystem on the other machine (RHEL4) is mounted via NFS to the RHEL5 machine. The destination filesystem is ext3 on an external permanently attached USB drive on the other machine. None of the filessystems show any errors when unmounted and fscked.
I'm able to reproduce that issue on my system even with the latest coreutils (6.9). You are right that info says that cp -a is the same as cp -dpPR , so I will try to find out the difference and fix it.
There is a rawhide package with fix included available - coreutils-6.9-11.fc9. So patch is known and hopefully will get into RHEL5 update soon.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
I'd like to suggest that getting this into an update soon should be a high priority. Anyone who might be using cp -a for backups in a similar context could easily be caught in a situation where the backups are corrupt due to this bug. Considering how important backups are in todays corporate environment - any bug which could lead to corruption in such a setting needs to be addressed as quickly as possible - particularly in operating systems targeted at large corporate and business customers.
*** Bug 427853 has been marked as a duplicate of this bug. ***
Looking at the sourcecode for coreutils-5.97-12.1.el5 (which seems to be the latest version), in cp.c (at about line 899) says that the -a option is equivalent to -dpPRc, and it seems to be the -c part of that which causes the problem. Running /bin/cp -c to an existing file on an fs which doesn't support selinux attributes (e.g. NFS or a local fs which presents context-setting (*)), shows up the bug. $ ls -al motd -rw-r--r-- 1 jp107 other 372 Jan 17 14:27 motd $ /bin/cp -c /etc/motd ./motd $ ls -al motd -rw-r--r-- 1 jp107 other 0 Jan 17 15:07 motd $ /bin/rm ./motd $ /bin/cp -c /etc/motd ./motd $ ls -al motd -rw-r--r-- 1 jp107 other 372 Jan 17 15:08 motd Looking in copy.c copy_reg() at about line 246 shows that it attempts to preserve the security context iff the file already exists but not otherwise. The code (#ifdef'd with WITH_SELINUX) quietly quits if the getfscreatecon() or fsetfilecon() calls fail - ie it doesn't attempt to copy the contents or do any other work. In any case it would be nice if it at least generated an error if the attempt failed (saying what it was doing). The info and man pages don't mention that -a now implies -c (well -c isn't mentioned at all), so this is at least a documentation error. Looking at the patch in coreutils-6.9-11.fc9 it seems to do the right thing (or at least tries to). Do you plan to release coreutils-6.9 for EL5 or backport this patch for coreutils-5.97? If the latter do you have a test patch we can look at or try?
Grr, I can't type. When I said: or a local fs which presents context-setting I meant: or a local fs which prevents context-setting in our case we mount some local file-systems with override contexts, e.g. /dev/FooSys00/scratch /local ext3 \ defaults,nosuid,nodev,quota,data=writeback,noatime,context=user_u:object_r:file_t:s0 1 2 just because we can and are feeling evil.
Created attachment 292026 [details] Patch which will make unability of storing of security context non-fatal in cp -a Thanks for your comments, but ... Please read my comment #2: "So patch is known and hopefully will get into RHEL5 update soon." Patch is known, backported to RHEL5, but there is an update process in RHEL which includes tests and verification to prevent regressions - and after that patch could be included in next maintainance release of RHEL5 (in this case RHEL5.2) . So please wait for that maintainance release for complete package. Anyway adding patch, I hope this will help you.
Part of the reason I added a comment was that anyone else searching for this problem may not have realised that it was just the security-context preservation (-c) which was causing the problem. I also wanted to point out (in case it wasn't obvious) that this doesn't *just* affect NFS file-systems. We really do have 'scratch' spaces mounted with context=... since all the files in there should always be in the same context, there is a slight performancs benefit and anyway we access many of them over NFS etc etc. Also comment #3 makes it seem (to me anyway) that it hasn't yet been decided if this is important enough to make it into a future maintenance release or not. Many thanks for the patch. It certainly looks (to my naked eye) like it should do the right thing. I understand that obviously you need to do rather more serious QA before releasing an update - even to fastbugs. I'll hopefully be able to build a test package with this extra patch to try on a few boxes here. Again many thanks for patch.
I should add that we have been using a version with that patch for quite some time now with no obvious ill effects. Again many thanks for this.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0310.html
I also encountered the same problem, but it seems only nfs version3. If I use: mount -t nfs -o vers=3 This bug 100% reproduction. But using: mount -t nfs -o vers=2 This bug will not reproduce. Summary bug reproduction requires three conditions: 1) use redhat 5.0 2) Use mount-t nfs-o vers = 3 3) use cp-a
(In reply to zhixin chen from comment #19) > I also encountered the same problem, but it seems only nfs version3. If I > use: mount -t nfs -o vers=3 This bug 100% reproduction. But using: mount -t > nfs -o vers=2 This bug will not reproduce. Summary bug reproduction > requires three conditions: 1) use redhat 5.0 2) Use mount-t nfs-o vers = 3 > 3) use cp -a overwrites file
I also encountered the same problem, but it seems only nfs version3. If I use: mount -t nfs -o vers=3 This bug 100% reproduction. But using: mount -t nfs -o vers=2 This bug will not reproduce. Summary bug reproduction requires three conditions: 1) use redhat 5.0 2) Use mount-t nfs-o vers = 3 3) use cp -a overwrites file