: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.

                                                -Matt

test28# 
        * 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
        itself.

test28# find .
.
./bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb1
./bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb2
./bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb3
./bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb4
                        ^^^^^^^^^^^^^^^^ it should not have returned this

./bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb6
./bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb7
./bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb8

Reply via email to