[Top][All Lists]
[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?
- Correct semantics in rm -rf ?, shailesh jain, 2009/08/25
- Re: Correct semantics in rm -rf ?, Jim Meyering, 2009/08/26
- Re: Correct semantics in rm -rf ?, shailesh jain, 2009/08/26
- Re: Correct semantics in rm -rf ?, Jim Meyering, 2009/08/26
- Re: Correct semantics in rm -rf ?, shailesh jain, 2009/08/26
- Re: Correct semantics in rm -rf ?, Jim Meyering, 2009/08/26
- Re: Correct semantics in rm -rf ?, shailesh jain, 2009/08/26
- Re: Correct semantics in rm -rf ?,
Jim Meyering <=
- Re: Correct semantics in rm -rf ?, shailesh jain, 2009/08/27
- Re: Correct semantics in rm -rf ?, Jim Meyering, 2009/08/27
- Re: Correct semantics in rm -rf ?, shailesh jain, 2009/08/27
- Re: Correct semantics in rm -rf ?, Jim Meyering, 2009/08/31