GNU bug report logs - #11074
Possible bug in cp from coreutils 6.12

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Philipp Thomas <pth <at> suse.de>
Subject: bug#11074: closed (Re: bug#11074: Possible bug in cp from
 coreutils 6.12)
Date: Tue, 08 May 2012 09:19:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#11074: Possible bug in cp from coreutils 6.12

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 11074 <at> debbugs.gnu.org.

-- 
11074: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11074
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: Philipp Thomas <pth <at> suse.de>
Cc: 11074-done <at> debbugs.gnu.org
Subject: Re: bug#11074: Possible bug in cp from coreutils 6.12
Date: Tue, 08 May 2012 11:16:20 +0200

Philipp Thomas wrote:
> I copy a file from one NFS export to another NFS export and execute
> it in the new location, I get a "'Stale NFS file handle' error at the second
> line "cp submit.sh $submit_sh":

Thanks.  I'm marking this as closed,
since the fix for http://bugs.gnu.org/11100
should address this problem, too.

[Message part 3 (message/rfc822, inline)]

From: Philipp Thomas <pth <at> suse.de>
To: bug-coreutils <at> gnu.org
Subject: Possible bug in cp from coreutils 6.12
Date: Fri, 23 Mar 2012 15:07:25 +0100

I copy a file from one NFS export to another NFS export and execute
it in the new location, I get a "'Stale NFS file handle' error at the second
line "cp submit.sh $submit_sh":

Here are the scripts:

script.sh:
#!/bin/sh
submit_sh=$HOME/submit_$$.sh
set -x
cp submit.sh $submit_sh
chmod 751 $submit_sh
ssh <some hostname> $submit_sh
#touch $HOME/
cp submit.sh $submit_sh
chmod 751 $submit_sh
ssh <some hostname> $submit_sh

submit.sh:
#!/bin/sh
echo Hello
rm -rf $0


A collegue analyzed the problem:

The problem is that 'cp' is being clever - too clever.

When you run 
  cp submit.sh $submit_sh

cp first checks if $submit_sh exists.  If it does, it just opens with
  O_WRONLY | O_TRUNC

in particular it doesn't include O_CREAT - after all it doesn't need to.
Maybe this is a bug in 'cp', but maybe this is intended behaviour.

In any case, when cp check if the file exists, NFS  thinks it does.  It
certainly did recently and as it is caching attributes it assumes that it
still does until proven otherwise.
Then when cp tries to open, it finds out that the file does exist, and
reports either "Stale NFS file handle" or "No such file or directory" - I've seen
both errors.

There is nothing that can be done in the NFS code to "fix" this except to
turn off attribute cache.

What is effectively happening is the file is disappearing between the
'lstat' and the 'open' and cp doesn't cope.

Options:
 - file a bug report against 'cp' suggesting that if the open fails, then it 
   should retry using O_CREAT.
 - don't use cp, just "cat submit.sh > $submit_sh" or similar.
 - use the "--remove-destination" argument to "cp".  This will cause it to
   remove the file (which might fail but that is ignored) before it tries to
   create it.

This was with cp from coreutils 6.12 on SLES11 SP1 and I didn't have time
yet to recheck with current coreutils.

Philipp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.