Bug 427853 - Overwriting a file on NFS volume results in zero-length file
Overwriting a file on NFS volume results in zero-length file
Status: CLOSED DUPLICATE of bug 320771
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
i386 Linux
low Severity medium
: rc
: ---
Assigned To: Ondrej Vasik
Depends On:
  Show dependency treegraph
Reported: 2008-01-07 16:12 EST by Trevin Beattie
Modified: 2008-01-07 16:15 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-07 16:15:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace output (2.63 KB, application/x-gzip)
2008-01-07 16:12 EST, Trevin Beattie
no flags Details

  None (edit)
Description Trevin Beattie 2008-01-07 16:12:07 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)

How reproducible:
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.

Actual results:
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.

Expected results:
The file size and contents should match the source file in both cases.  cp
should have exited with status 0.

Additional info:
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.
Comment 1 Trevin Beattie 2008-01-07 16:12:08 EST
Created attachment 291013 [details]
strace output
Comment 2 Ondrej Vasik 2008-01-07 16:15:49 EST
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 ***

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