Red Hat Bugzilla – Bug 427853
Overwriting a file on NFS volume results in zero-length file
Last modified: 2008-01-07 16:15:49 EST
Description of problem:
If I use 'cp' to overwrite an existing file on an NFS volume, the destination
file is truncated to 0 bytes and cp exits with a status of 1 without having
copied any data from the source file. No errors are displayed.
If I first remove the destination file, then cp will correctly copy the file
without any error. Both rsync and scp will copy the file without any problems
whether the destination already exists or not.
Version-Release number of selected component (if applicable):
kernel-2.6.18-8.el5 (both client and server)
Always, though I only have one pair of test servers running RHEL 5. (Most of
our systems are still on RHEL 3.)
Steps to Reproduce:
1. Establish a writable mount point from an NFS server to the test system.
2. Copy a small test file to the NFS-mounted directory. Run 'ls -l' to check
the file size.
3. Using cp, copy the test file to the same destination again. Issue "echo $?"
to check the exit status. Run 'ls -l' to check the file size.
The file size matches the source file after the first copy (new) but is 0 after
the second copy (overwrite). cp exited with status 1.
The file size and contents should match the source file in both cases. cp
should have exited with status 0.
The problem seems to be caused by an "Operation not supported" error from a call
to fsetxattr on the destination file. This call is *not* made when the
destination file is created anew, only when overwriting an existing file. I
have attached strace output from both cp runs. Memory addresses and process
ID's have been masked so that the diff between the two runs is more apparent.
The security settings on the server might make a difference. The firewall is
disabled, and SELinux is set to "Permissive" mode. I tried changing the SELinux
setting to "Disabled" but still see the error.
Created attachment 291013 [details]
Thanks for report. Problem is known, is fixed in Fedora, will be fixed in next
maintainance release of RHEL5. This bug report is duplicate of #320771.
*** This bug has been marked as a duplicate of 320771 ***