On 2007-03-05 16:02:54 -0800, Paul Eggert wrote:
> Read the directory, removing files as we go.
> getdents64(4, /* 15 entries */, 8192) = 472
> lstat("/proc/self/fd/4/config.h.in", {st_mode=S_IFREG|0644, st_size=27828,
> ...}) = 0
> access("test/config.h.in", W_OK) = 0
> unlink("/proc/self/fd/4/config.h.in") = 0
> ...
> getdents64(4, /* 0 entries */, 8192) = 0
>
> Rewind the directory.
> lseek(4, 0, SEEK_SET) = 0
>
> Read the directory again, removing files as we go again.
> getdents64(4, /* 15 entries */, 8192) = 472
> lstat("/proc/self/fd/4/config.h.in", {st_mode=S_IFREG|0644, st_size=27828,
> ...}) = 0
> access("test/config.h.in", W_OK) = -1 ESTALE (Stale NFS file handle)
> unlink("/proc/self/fd/4/config.h.in") = -1 ENOENT (No such file or
> directory)
> open(".", O_RDONLY) = 3
> fchdir(4) = 0
> unlink("config.h.in") = -1 ENOENT (No such file or
> directory)
> fchdir(3) = 0
> close(3) = 0
> write(2, "rm: ", 4) = 4
> write(2, "cannot remove `test/config.h.in\'", 32) = 32
>
> That ESTALE result, if we propagated it to the caller, could be a hint
> that our bug-workaround is causing trouble, and could cause 'rm' to
> suppress the diagnostic.
>
> A simpler possibility would be to rip out the bug-workaround entirely,
> at least on non-MacOS hosts. (After all, once your NFS server is
> buggy all bets are off....)
The problem here is the NFS *client*, isn't it? And I'm not sure this
is really a bug of the NFS client, knowing the fact that NFS works
asynchronously. Concerning the ESTALE error,
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/access.htm
(found by Google) says:
File or object handle rejected by server.
If you are accessing a remote file through the Network File
System, the file may have been deleted at the server.
The NFS client seems to behave correctly.
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
