Re: rm -r sometimes produces errors under NFS

[Vincent Lefevre]

On 2007-03-06 20:45:24 +0100, Jim Meyering wrote:
> Vincent Lefevre <address@hidden> wrote:
> > On 2007-03-06 15:17:07 +0100, Jim Meyering wrote:
> >> Such "remembering" would be prohibitively expensive, in general.
> >
> > I don't see why.
> 
> Remembering means storing names, potentially many of them.
> That's why it would be prohibitively expensive.

No need to store names: if it's the second pass, all the files have
already been unlinked.

> > 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.
> 
> No.  Any POSIX-conforming rm implementation is required to
> report such errors, unless you specify -f.

Wrong. In the recurse phase, if rm tries to unlink a file, this means
that the file has existed. So, this wouldn't be contrary to POSIX.

> >> It sounds like your client NFS implementation's cache is not coherent,
> >
> > This is a feature of NFS.
> 
> [btw, the above is an incomplete quote of what I wrote.]
> No, it's not (because of the qualifying phrase you omitted).

It is. Look at the many things that don't work under NFS because of that.
The fact that readdir says that the file still exists, perhaps not. I'll
report a bug about that.

> > A full-synchronized NFS implementation
> > would be too slow (if not impossible, due to race conditions).
> 
> No one is advocating a fully-synchronized NFS implementation.
> When an NFS client sees a successful unlink, it is reasonable to
> expect a client-side rewinddir/readdir sequence *not* to produce
> the just-unlinked name.  I hope this sort of coherence (between
> an unlink syscall and a subsequent rewinddir/readdir) is guaranteed
> by a standard.

But there's still a race condition (unrelated to NFS) in the rm code.

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