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):
coreutils-5.97-12.1.el5
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.