>>>True, for ADIR it may not be such a good solution due to the 64K elements limitation of arrays. It's amazing how fast the number of files in a folder "mushrooms" out of control, isn't it! I have some systems with 2 or 3 hundred K files on them (not all in one folder), and I know what each and every one of those files are for/do. (Yeah, right!)
>>
>>The worst I've seen was 1500 files in one directory, and the system was darn slow with that app (other apps which used shorter directories were comparably faster). It was back in DOS 5.0 and, well, we were told that whenever you are opening a file, the DOS searches the directory sequentially. Since then, I'm trying to reduce the number of files my apps use. Now with W9x and NT, I'm not sure anymore - does the OS still search the directory sequentially, or is it finally indexed (I remember VAX VMS had indexed directories 14 years ago)?
>
>I defer to Ed's superior knowledge on the subject, but it was as I suspected. 95/98 still do it the old fashioned way, since it's still essentially DOS based!

You're absolutely correct, and it's not just Win9x that creates the issue - it's any FAT volume on Win9x or WinNT. NTFS uses an index structure which speeds things up, and for once, but FAT on NT is searched just as poorly as it is under Win9x, searching the directory is sequential, entry by entry. I'll deny ever saying anything nice about Novell if I'm asked, but NetWare does exactly what I'd want done to manage its directories, caching the currently referenced directories and using hash tables for directory lookups - NetWare is probably shown in its best light for file performance working with overpopulated directories.

It doesn't matter what operating system the station issuing the directory lookup is running, it's the file system in use at the server (for all intents and purposes, working on a local volume, you are your own server for purposes of this discussion.)