[lkml]   [2005]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC,PATCH] libfs dcache_readdir() and dcache_dir_lseek() bugfix
    On Fri, Nov 04, Miklos Szeredi wrote:

    > > As I said: "Old glibc implementations (e.g. glibc-2.2.5) are
    > > lseeking after every call to getdents() ..."
    > Hmm, why would it do that? This seems like it's glibc being stupid.

    Well, glibc is that stupid and triggers the bug.

    > That said, you are right that the libfs readdir implementation is not
    > strictly standards conforming. But neither is your patch: this
    > algorithm will break if the entry at the current position is removed
    > and then a new entry with the same name is created.

    True. Seeking to that offset should at least fail and shouldn't stop at the
    new entry. But SuSV3 says that the offset given by telldir() is valid until
    the next rewinddir(). This is no problem for directories that can only grow.
    I tried to implement some kind of deferred dput'ing of the d_child's but that
    was too hackish and was wasting memory. So the best thing I can do now is fail
    if someone wants to seek to an offset of an already unlinked file.

    So I can include the inode number in the hashing process somehow. Any ideas on
    that one?

    > Unfortunately I can't since I don't have such old glibc.

    The testcase is similar to what "rm *" with the old glibc would do. It just
    a testcase to show where the problem is.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-04 16:13    [W:4.834 / U:0.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site