pay@tention.uucp (David Gibbs) (06/23/89)
I am about to write a program that needs to find all files and directories on a list of drives. I have reviewed the DOS function calls and found "findfirst" and "findnext" will do what I need. I believe that the OS (PCDOS or MS-DOS) already reads a full directory at a time into some memory structure under some "reserved" function call. This seems logical since an operator doing a "dir" command will see drive access the first time, but a second "dir" does not access the drive. It would greatly speed up my program if I could access the directory information that DOS contains, instead of finding each directory entry; one by one. I do not want to read the FAT, since I might wish to port this program to unix later. Does anybody out there know where DOS stores the directory and what the structure definition for that memory space is OR is there a function call that does this and which one is it and how do I use it? THANX (in advance) David Gibbs
tim@j.cc.purdue.edu (Timothy Lange) (06/23/89)
I think you are seeing the result of disk buffering. The first DIR command had to go to the disk, the second just read what got buffered. How many buffers are set in your CONFIG.SYS? How many files in the directory you looked at? -- Tim Lange. Purdue U. Computing Center/MATH Bldg./W. Lafayette, IN 47907/317-494-1787 Arpanet=tim@j.cc.purdue.edu CIS=75410,525 Bitnet=TIM@PURCCVM
mike@relgyro.stanford.edu (Mike Macgirvin) (06/24/89)
In article <33856@tention.uucp> pay@tention.uucp (David Gibbs) writes: >I am about to write a program that needs to find all files and directories >on a list of drives. I have reviewed the DOS function calls and found >"findfirst" and "findnext" will do what I need. I believe that the OS >(PCDOS or MS-DOS) already reads a full directory at a time into some >memory structure under some "reserved" function call. This seems logical >since an operator doing a "dir" command will see drive access the first >time, but a second "dir" does not access the drive. It would greatly >speed up my program if I could access the directory information that >DOS contains, instead of finding each directory entry; one by one. >I do not want to read the FAT, since I might wish to port this program >to unix later. >Does anybody out there know where DOS stores the directory and what >the structure definition for that memory space is OR is there a function >call that does this and which one is it and how do I use it? Let me get this straight: You don't want to access the FAT because of porting issues, but reading an internal DOS table is OK? How do you port THAT? Oh well, yes DOS actually does store directory info. You can poke through your system memory and find it. It is stored, I believe, by COMMAND.COM. Internal commands, such as DIR and CD, can use it, because they know the address. This is highly dependant on the DOS version, and the location is almost guaranteed to change with versions of COMMAND.COM. There are no DOCUMENTED system calls that will touch this, and the UNDOCUMENTED calls aren't documented because they almost invariably change or go away. As I recall, the structure of this memory was exactly as it is on the disk. To speed up your program, I recommend allocating space for the entire directory, gobbling it up with one read(), and then you have duplicated what DOS does. Your program can then scan through this memory as it wishes. If you are careful about not depending on the internal structure of this memory, i.e. if all you are after is filenames, you could use the same technique under unix. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + These views are my own, and may not be correct. + + Mike Macgirvin + + - Systems Administrator Stanford Relativity Gyroscope Experiment + + - Internet: mike@relgyro.stanford.edu (36.64.0.50) + + - Bitnet: mike%relgyro.stanford.edu@stanford + + - Uucp: uunet!relgyro.stanford.edu!mike + + "There must be some kind of way out of here." - Dylan (w/help from Jimi) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++