>I agree it would be more efficient to work this way but it's not obvious to me that that's the way it actually works. I haven't yet had a chance to dig up some references to HD file I/O which, as I mentioned earlier, is part of what's needed to answer this question.

Well, from reading I did some time ago, I think I have some basic understanding of the file system used by DOS (FAT, or FAT16), and by Windows 98 and some other operating systems (FAT32).

These systems divide the hard disk into clusters, which may vary between 1 and 64 sectors (1/2 to 32 KB). Bigger clusters mean more wasted space, since a file uses 1, 2, etc. clusters (an integer), but a cluster can't be shared by two files.

A FAT (file allocation table) has 2 or 4 bytes for each cluster on disk (2 for FAT16). This table keeps track of what clusters are used and unused, what clusters are bad, and the allocation chain for a file. For instance, say you have a non-fragmented file that uses 3 (contiguous) clusters. It starts on cluster #100.

The FAT would look like this:

FAT entry #   100     101     102
Value         101     102    <EOF>

Each entry in the FAT says where the NEXT entry is.

So, it is my guess that if you need to access the third cluster, you follow the allocation chain, and, in the example above, find that the third cluster of the file is stored in cluster #102 for the partition.

The file itself doesn't have to be read (except for the requested third cluster). The position can be deduced from the FAT; and the FAT is probably already cached in RAM.

Hilmar.