in reply to perlbug: seekdir/readdir broken on win32 on 5.008009, 5.012002, 5.014001

So after reading Re: perlbug: seekdir/readdir broken on win32 on 5.008009, 5.012002, 5.014001 I looked up some of these system library seekdir docs

http://www.delorie.com/gnu/docs/dirent/directory.3.html
Telldir and seekdir are unreliable when used in conjunction with file systems that perform directory compaction or expansion or when the directory stream has been closed and reopened. It is best to avoid using telldir and seekdir altogether.

http://www.vnode.ch/fixing_seekdir# When seekdir() Won't Seek to the Right Position | vnode.ch

(and sorry that it took us almost twenty-five years to fix it)

Yes, I think I will avoid seekdir/telldir as much as possible

  • Comment on Re: perlbug: seekdir/readdir broken on win32 on 5.008009, 5.012002, 5.014001

Replies are listed 'Best First'.
Re^2: perlbug: seekdir/readdir broken on win32 on 5.008009, 5.012002, 5.014001
by ikegami (Patriarch) on Nov 27, 2011 at 10:15 UTC
    Caveats about a POSIX system call aren't very relevant on a Windows system. As far as I know, Windows doesn't even have an equivalent to seekdir. If I remember correct, Perl emulates seekdir on Windows by caching previously seen entries.
      I am curious about this function (seekdir).
      It just sounds like a "solution in search of a problem"?

      I do most of my programming on Windows, but some on *nix. But even so, how many directory entries would one need in order for this type of a function to be "worthwhile" in terms of performance or memory? 1K? 10K? 50K? My mind boggles at directories of such sizes.

        You can bet graphical file explorers make use of it

        And you can bet they have been using it since 64kb of storage was plenty (or whatever the saying is)