Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
I was wondering how the MS-DOS 6 DIR command works. I noticed that the floppy drive directory is cached so that the drive isn't read again when you run DIR a second time. In thinking there may be a situation where I want to force it to refresh the DIR results, I need to understand how it works so that I can code a utility to force a refresh.
Just running on a typical 486 MS-DOS 6 machine.
Hard to answer without knowing what DOS (MS, DR, ...) in what configuration and on what machine - or emulation thereof - this observation has been made.
So here just a rough overview of the general development:
DOS 1.x had dedicated buffers for various jobs. At least one for a single directory and a data sector - there might have as well been one for the FAT - for each drive.
DOS 2.0 introduced a more generic low level buffer management, seen in BUFF.ASM. It offered a series of file access buffers which could be set between 1 and 99 using the BUFFERS= option of CONFIG.SYS. Without a default value of MS-DOS was two. PC-DOS did set it according to system configuration:
Those buffers were used for all disk access, regardless of sector type - although different use got different priority, FAT over Directory over Data.
Buffers are the essential building blocks of any nice and convenient high level function, like partial read from a sector, record wise operation, indexed access or alike. Just think of a file made up of fixed length records holding some journal one wants to read. Noone fetching one or more thereof wants to go thru the hassles of blocking/unblocking of records into sectors all the time, would you?
More so as sector size is a device and OS dependent value. So it should be the OSes task to provide some simple get-record/get-next-record function, shouldn't it? Then again, having such functions might perform quite terrible if reading a record would always include reading the sector - even with perfect timing that gets the speed down to 5 records a second. Same for every record write - and ways worse considering that Unix style character based read and write is standard today.
And that's where buffers come into play. Here DOS keeps some of the sectors last read to be peaked into again or modified with functions of different granularity. The speed gain is quite considerable. Just imagine a record size of maybe 32 bytes. With 512 byte sector 16 of them would be packed into a sector. Reading them sequential using a nice high level read-first/read-next interface would mean 16 reads, but having a buffer will get that down to a single read and 15 times just peeking into the buffer.
Sounds great, doesn't it?
Heck, it gets even better when reading past that sector, as now the system has to find the next one reading the FAT. With buffers, the FAT may still be in memory so it saves another read.
BTW, did I mention that a directory is simply a data base file with fixed size records of 32 bytes each? Or that COMMAND.COM is a very average user program using a high level find-first/find-next API to scan it?
Without Buffers a PC would be slower than a C64 (*2).
All read buffers have a life time of 2 seconds. After that they are invalidated. This was the direct result of tests done during development. (*1)
does not cache any FD or HD access in any way - that is, beside the buffers. COMMAND.COM does not cache the results of a directory scan, but restarts each time using the standard functions for directory access, like any other application.
In fact, in all DOS versions prior to 3.0, COMMAND.COM only uses the FCB based routines of INT 21h (Function 11h/12h). The new, Xenix like, Find First/Next calls (4Eh/4Fh), are not used, as seen in the source code (*3)
mechanics for buffer management were introduced to support networking, but DOS does (AFAIK) still use only write buffers. Management was made thru the new multiplex interrupt INT 2Fh using function group 12h.
With DOS 4.01, in 1988, and Windows 3.0, in 1990, SMARTDRIVE was added providing a way to use RAM for disk buffering - although its main purpose was to make sure bus master controllers would always find their data buffers in conventional memory.
Due the changes in DOS 3.0 all of this should be robust against parallel access and disk changes.
Every user of a file can of course flush its buffers by calling INT 21h function 68h Commit File. It will update all data blocks and directory entries.
Already since DOS 1.0 INT 21h Function 0Dh Disk Reset can be used to flush all unwritten buffers of all disk drive.
INT 2Fh offers several functions to manage the disk buffers, including invalidating, but these calls can only be made from within DOS, as they need a very specific environment. Also structures handled may differ between DOS versions.
In thinking there may be a situation where I want to force it to refresh the DIR results, I need to understand how it works so that I can code a utility to force a refresh.
It would be quite interesting to learn what situation that could be and how they may be invoked.
*1 - No, someone managing to do a disk swap in less than two isn't proving anything for real life usability.
*2 - Then again, a genuine 4.77 MHz IBM-PC isn't that much faster either.
*3 - The 2.x DOS kernel as well was still based around FCB calls. Much of the speed gain in DOS 3.0 was by flipping this. All disk access was rewritten to use Xenix calls as primary implementation. FCB calls were only provided as a compatibility layer atop the Xenix versions.
MS-DOS 6 introduced SMARTDRV which was a proper read cache driver, and it could also be configured for write cache. So you could easily retrieve data from a floppy and then the next time it wouldn't need to physically read it again. SMARTDRV was great, sped up systems enormously. There was never a need to manually refresh SMARTDRV's cache because if an edit was made to the disk, SMARTDRV knew about it.
