Re: rm -r sometimes produces errors under NFS

[Jim Meyering]

Vincent Lefevre <address@hidden> 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.

Unfortunately it's not that easy.
If I were to make such a change, it is quite likely
that it would cause a real unlink failure not to be
reported, and *that* would be serious.

Here, you have a work-around (use -f) that works just fine.

>> > courge:~> strace -o test.log rm -r test
>> > rm: cannot remove `test/config.h.in': No such file or directory
>>
>> Does using -f solve your problem?
>
> Yes.

Good!