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
