Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#66 readdir error with rm -r

open
nobody
None
5
2003-08-30
2003-08-30
Anonymous
No

This is a generic problem, not tied to a particular
filesystem.
As far as I have undestood, if a program makes a call
to ::opendir and then some calls to ::readdir, lufs makes
a call to do_readdir on the first readdir, and chaches the
results for the subsequent ::readdir. If the directory
contains a lot of files, the cache is not big enough, so at
some ::readdir in the middle lufs has to make another
call to do_readdir, remember where it was, and go on
from there.
But with "rm -r directory_with_a_lot_of_files/", this thing
does not work. When in recursive mode, rm makes
an ::opendir and then ::readdir, calling ::unlink for every
entry.
So, the second (and third, and so on) call to do_readdir
will return a different list than the first do_readdir
(because in the meantime the first files have been
deleted), and the index that tell where to continue is
meaningless.
Let me make an example. Directory /a/ on the lufs fs has
ten files 0 1 2 3 4 5 6 7 8 9.
The first do_readdir will return 0 1 2 3 4 5 6 7 8 9, let's
suppose lufs caches entries till 3.
rm: ::readdir -> 0 -> ::unlink(0)
rm: ::readdir -> 1 -> ::unlink(1)
rm: ::readdir -> 2 -> ::unlink(2)
rm: ::readdir -> 3 -> ::unlink(3)
rm: ::readdir -> call to do_readdir, that returns 4 5 6 7 8
9. The internal counter says to begin from the fifth
element, and rm gets (and unlinks) file 8
after that ::readdir returns NULL, rm thinks he has
deleted all the files in the directory, while 4 5 6 7 are
still there.

Discussion

  • Guido
    Guido
    2003-08-30

    Logged In: YES
    user_id=855537

    sorry, the bug was submitted by me, I forgot to login before
    submitting.