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?
