bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rm -r sometimes produces errors under NFS


From: Vincent Lefevre
Subject: Re: rm -r sometimes produces errors under NFS
Date: Tue, 6 Mar 2007 02:21:39 +0100
User-agent: Mutt/1.5.14-vl-r16324 (2007-03-03)

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 <address@hidden> - 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)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]