Re: rm -r sometimes produces errors under NFS

[Jim Meyering]

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.

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

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

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