Re: Correct semantics in rm -rf ?

[shailesh jain]

On Wed, Aug 26, 2009 at 3:07 PM, Jim Meyering <address@hidden> wrote:

> 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.
>


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

Given that you plan to remove remove.c, you might not want to do it. But
really it's just one call to rewinddir() :) which will make POSIX-confirmers
(like me) happy as well.

Anyways I think I am done with my blabbering here ;). Thanks for your time !




> > 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)                           = ?
>