Re: rm -r sometimes produces errors under NFS

[Vincent Lefevre]

On 2007-03-06 15:17:07 +0100, Jim Meyering wrote:
> Such "remembering" would be prohibitively expensive, in general.

I don't see why. In fact, it isn't necessarily useful to remember
anything. When rm attempts to remove a file in a recurse phase,
no errors should be reported if the file doesn't exist.

> It sounds like your client NFS implementation's cache is not coherent,

This is a feature of NFS. A full-synchronized NFS implementation
would be too slow (if not impossible, due to race conditions).
Even disabling attribute caching only (with the noac option),
makes some NFS accesses very slow.

> at least in some respect.  The client has successfully unlinked a file,
> yet after a rewinddir, a subsequent readdir gets the same name; that
> suggests the dir entry is out of date:  it doesn't reflect operations
> the client itself has marshaled.

This is not exactly true. At this time, the dir entry may still exist
on the server side. Then there's the question of whether dir operations
should reflect what is on the server or on the client. The observed
behavior is bad, but I wonder if this can be called a bug or if there
is any reason to behave like that (BTW, this is a 2.6.18 Linux kernel).

Moreover even on a fully-compliant POSIX system, it is possible to
get a dir entry for some file, but when rm tries to unlink the file,
it no longer exists (there's a race condition here).

-- 
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)