Re: Correct semantics in rm -rf ?

[shailesh jain]

Here it is.
Outcome is that Child gets deleted but parent does not get deleted.
(Now you will say it's a filesystem issue ;) ....)


fstatat64(AT_FDCWD, "parent", {st_mode=S_IFDIR|0755, st_size=72, ...},
AT_SYMLINK_NOFOLLOW) = 0
unlinkat(AT_FDCWD, "parent", 0)         = -1 EISDIR (Is a directory)
openat(AT_FDCWD, "parent",
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW)
= 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
fstat64(3, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
fcntl64(3, F_GETFL)                     = 0x28800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW)
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
fstat64(3, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
getdents64(3, /* 3 entries */, 1024)    = 80
openat(3, "Child", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=48, ...}) = 0
fstat64(4, {st_mode=S_IFDIR|0755, st_size=48, ...}) = 0
fcntl64(4, F_GETFL)                     = 0x28800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW)
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
close(3)                                = 0
fcntl64(4, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
fstat64(4, {st_mode=S_IFDIR|0755, st_size=48, ...}) = 0
getdents64(4, /* 2 entries */, 1024)    = 48
getdents64(4, /* 0 entries */, 1024)    = 0
fcntl64(4, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
openat(4, "..", O_RDONLY|O_LARGEFILE)   = 3
close(4)                                = 0
fstat64(3, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
unlinkat(3, "Child", AT_REMOVEDIR)      = 0
fstat64(3, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
fcntl64(3, F_GETFL)                     = 0x8000 (flags
O_RDONLY|O_LARGEFILE)
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
fstat64(3, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
getdents64(3, /* 3 entries */, 1024)    = 80
openat(3, "Child", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW) = -1
ENOENT (No such file or directory)
getdents64(3, /* 0 entries */, 1024)    = 0
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
close(3)                                = 0
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?


Shailesh Jain



On Thu, Aug 27, 2009 at 3:44 AM, Jim Meyering <address@hidden> wrote:

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

log
Description: Binary data