Bug #1000

Seekdir Bug (patch problems)

Added by dillon over 8 years ago. Updated about 8 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


:There is a bug in all seekdir()/readdir() implementations in all BSDs:
:Under some circumstance, a seekdir() will no take you to the expected
:position, but one further. This happens when the first entry in a
:block has been unlinked and you seekdir to the second. In this case
:seekdir() overshoots by one entry.
:_readdir_unlocked() must not skip deleted entries when being called
:from _seekdir().
:A diff is attached.
:- Marc Balmer

Oops, I tried applying the patch, cleaned up a few minor compiler
errors, but something isn't working properly because readdir is
now returning a few whiteout entries along with everything else.


* create files bbbb....1, 2, 3, 4, 5, 6, 7, 8 in an empty directory
* rm *4 and *5
* find .

Note that it is returning *4, which is a whiteout. If I leave the
patch intact but comment out the skipdeleted condition then
find . does not return the *4 entry.

I haven't dug down to figure out why it is returning a whiteout.
It is very odd.

All find does is call readdir(). It doesn't do any seek/tells

test28# find .
^^^^^^^^^^^^^^^^ it should not have returned this



#1 Updated by otto over 8 years ago


The diff posted has the logic reversed, that's why it does not work.


Also available in: Atom PDF