Re^3: perlbug: seekdir/readdir broken on win32 on 5.008009, 5.012002, 5.014001

[Marshall]

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.

[Anonymous Monk]

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)

[ikegami]

A graphical explorer wouldn't use this. Not now, not in the days of text-based windowing systems. They need to load the entire directory into memory in order to sort the file names.

[Anonymous Monk]

A graphical explorer wouldn't use this. Not now, not in the days of text-based windowing systems. They need to load the entire directory into memory in order to sort the file names.

Sure, whatever you say, you know all implementation of all explorers by heart, and you can't sort data unless its all in memory at the same time

[patcat88]

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx Memory makes no difference. The underlying Win32 API is an enumeration. So is the Native API http://msdn.microsoft.com/en-us/library/windows/hardware/ff567047%28v=vs.85%29.aspx. You start it, and it keeps going slice by slice until it errors out with "no more files". According to ReactOS, the kernel and its drivers dont make a mega list with every entry in ram, which would justify seeking. They advance a counter every time you fetch an entry. http://doxygen.reactos.org/d5/d16/ntfs_2dirctl_8c_source.html#l00481