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:
- 2 for a 128 KiB RAM with 180 KiB-Diskette
- 3 for a 128 KiB RAM with 360 KiB-Diskette
- 5 for 128 to 255 KiB RAM
- 10 for 256 to 512 KiB RAM
- 15 for 512 KiB and over
Those buffers were used for all disk access, regardless of sector type - although different use got different priority, FAT over Directory over Data.
Buffers Maketh System (Go)
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).
Buffers are Only Valid For Two Seconds
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)
Classic MS-DOS (Before 3.0)
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)
Starting with DOS 3.0
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.
Management Calls Available
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.