On Wed, Aug 26, 2009 at 3:07 PM, Jim Meyering <[email protected]> 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) = ? >
