Re: Correct semantics in rm -rf ?

[Jim Meyering]

shailesh jain wrote:
> I have attached a log file. Note I have ran this on local file system where
> rm -rf works not on Network file system (I was running into some issues
> which I am trying to resolve ..).  However, this run also gives us lot of
> information and demonstrates that even though rm -rf works, it is does not
> seem to be POSIX compliant.

The key word there is "seem".
If you see behavior from rm that *is* not POSIX compliant,
given compliant infrastructure, then I'll be happy to investigate it.
So far, I've seen nothing to suggest there is an actual
problem with GNU rm.  An example might be if rm -ir were to
prompt twice about the same file.

Perhaps the Hgfs file system has semantics that are different
from most file systems in common use?

> Thus any filesystem that reflects updates only on open() will break. If you
> also want me to run on a filesystem that breaks rm -rf, I will go through
> the pain of setting it up ?

If it's that hard to set up, perhaps it's only a toy,
and few people are using it.  In that case, given its unusual
semantics, it may not be worth spending any more time on, here.

Also, bear in mind that I expect to replace remove.c
with an implementation based on lib/fts.c very soon.

> Let me know if you need any other information. (Btw. The file system that I
> was talking about is Hgfs (Host/ Guest file system) located at
> http://open-vm-tools.sourceforge.net/)
>
...
> getdents(4, /* 0 entries */, 8192)      = 0
> fcntl(4, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
>
>
> /* Open 'parent' directory */
> openat(4, "..", O_RDONLY)               = 3
>
> /* Close 'Child' directory */
> close(4)                                = 0
> fstat(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>
> /* Remove 'Child' directory*/
> unlinkat(3, "Child", AT_REMOVEDIR)      = 0
>
> fstat(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl(3, F_GETFL)                       = 0x8000 (flags
> O_RDONLY|O_LARGEFILE)
> fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
> fstat(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>
> /* 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.

> getdents(3, /* 2 entries */, 8192)      = 48
> getdents(3, /* 0 entries */, 8192)      = 0
> fcntl(3, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
> close(3)                                = 0
> unlinkat(AT_FDCWD, "parent", AT_REMOVEDIR) = 0
> close(0)                                = 0
> close(1)                                = 0
> close(2)                                = 0
> exit_group(0)                           = ?