Mikulas Patocka <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
