Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> On 2007-03-05 19:07:31 +0100, Jim Meyering wrote:
>> Your log shows that rm succeeds in removing each file (all unlink syscalls
>> succeed), yet the directory is not empty, so it rewinds it and goes
>> through again -- and all names are still there. The _second_ unlink
>> attempt fails with ENOENT, because now NFS is reporting that it's gone:
>>
>> access("test/config.h.in", W_OK) = 0
>> unlink("/proc/self/fd/4/config.h.in") = 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)
>>
>> But the solution for ignoring diagnostics about nonexistent
>> files is simply to use rm's -f option.
>
> But IMHO, rm should remember that is has already done an unlink and
> there shouldn't be a diagnostic in this case.
Such "remembering" would be prohibitively expensive, in general.
The file system is supposed to do that.
Actually it looks like POSIX expects a certain amount of
synchronicity of rewinddir. From the POSIX spec for readdir:
If a file is removed from or added to the directory after the most
recent call to opendir() or rewinddir(), whether a subsequent call
to readdir() returns an entry for that file is unspecified.
Obviously, that doesn't require precisely what we want, but it
sort of implies that the desired rewinddir behavior is expected.
It sounds like your client NFS implementation's cache is not coherent,
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.
FYI, here's the relevant bit from the description of rewinddir:
The rewinddir() function shall reset the position of the directory
stream to which dirp refers to the beginning of the directory. It shall
also cause the directory stream to refer to the current state of the
corresponding directory, as a call to opendir() would have done.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
