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.
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!
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
