bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Correct semantics in rm -rf ?


From: Jim Meyering
Subject: Re: Correct semantics in rm -rf ?
Date: Thu, 27 Aug 2009 09:44:22 +0200

shailesh jain wrote:
...
>> > /* Now get directory entries of 'parent'. There are no guarantees that
>> > updates should have been reflected here, but rm -rf assumes this! Updates
>> > are guaranteed to be reflects only on next openat() */
>>
>> Or rewinddir.  In practice, only a few unusual (I'd say crufty) file
>> systems have had problems here.  Hence the periodic rewinddir call,
>> when deemed necessary.  I think one was hfs on MacOS of a few
>> years ago.  That version of that OS appears no longer to be relevant.
>>
>
>
> Yes, that is what I expected to have either rewinddir() or Close()/Open()
> call.  I agree that 'rm -rf' will work on most (if not all) filesystems but
> clearly just because if works on most filesystems does not make it
> compliant.
>
> And thus I do not understand when you say "If you see behavior from rm that
> *is* not POSIX compliant, given compliant infrastructure, then I'll be happy
> to investigate it."
>
> It clearly isn't.

How can it be clear when you have not demonstrated a failure?
Did rm -rf fail to remove a hierarchy that POSIX specifies it must?
Your strace output did not show any failure.

While rm -rf may do extra work on a file system like you describe,
I would be surprised if rm -rf fails to conform, since
with -rf, rm ignores any failure due to e.g., ENOENT.

> Underlying file-systems are not required by POSIX to
> respect the assumption that 'rm' is making. Why not have a rewinddir() call
> there  ?

Try it, and you'll see that performance is affected.

This might do it:

-    CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 10
+    CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 1

> Given that you plan to remove remove.c, you might not want to do it. But

I have rewritten the core of remove.c.  I'm not removing the file.

> really it's just one call to rewinddir() :) which will make POSIX-confirmers
> (like me) happy as well.

IMHO, you still haven't shown how rm fails to conform.
Did you demonstrate how rm -rf fails?
Did you demonstrate how some other invocation of rm fails?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]