Re: PATCH: rm -rf and readdir bug in coreutils-6.7

[Mikulas Patocka]

> Mikulas Patocka <address@hidden> wrote:
> > I have a system that precaches directory content at opendir call and I
> > found that coreutils-6.7 rm -r command doesn't work on it (it used to work
> > fine in coreutils 5).
> >
> > The problem is this: when walking up to the root in directory tree, rm
> > opens parent directory with opendir, then deletes its subdirectory with
> > rmdir and then starts reading the parent with readdir --- readdir reads
> > just deleted entry, rm tries to delete it again and fails.
> >
> > opendir caching is allowed by standard
> > http://www.opengroup.org/onlinepubs/007908799/xsh/readdir.html ("If a file
> > is removed from or added to the directory after the most recent call to
> > opendir() or rewinddir(), whether a subsequent call to readdir() returns
> > an entry for that file is unspecified."), so the system behaves correctly
> > and rm has a bug.
>
> Thank you for the detailed report and the patch.
> Does your file system have a name?  Oh, ok -- from your follow-up
> message I see it must be SPADFS.

It is SpadFS, but not on Linux (there it uses generic Linux glibc 
readdir), but on experimental not-yet-released kernel.

> So far, your patch looks fine, modulo the fact that it makes
> AD_pop_and_chdir set *dirp = NULL unconditionally -- better to change its
> signature in that case.  I'll look at it more closely today or tomorrow.
> Also, since the modified function no longer even calls fdopendir, the
> "_and_chdir" part of its name is truly inaccurate.  Good excuse to rename.

Code surely needs cleanup, I tried to make patch the smallest. You don't 
have to pass double pointer to AD_pop_and_chdir at all, DIR *dirp would be 
enough, and you can set it to NULL in the caller. Setting to NULL is 
needed because of error path. Also you can test longjmp error branch, if 
you commit it (I just copied it but did not test if all gets released 
right on it).

Mikulas