-=> Quoting MIKE RUSKAI to MURRAY LESSER <=-

 MR> What I did instead was write a program to traverse the freespace
 MR> bitmaps on the drive "manually", and count up the free sectors that
 MR> way.  On every drive in my system, the result was that DosQueryFSInfo()
 MR> returned 4096 sectors too few in free space.  The reported free space
 MR> is firm, however, when attempting to write to the drive.  The write
 MR> fails at that value, not the value computed by tallying the freespace
 MR> bitmaps. 
 MR> So it would seem that there's a bug somewhere in the chain that eats
 MR> 2MB of space when using HPFS.  The number isn't related to drive
 MR> geometry, either. The one drive is addressed with 63 sectors per track,
 MR> and 64 tracks per cylinder (heads).  Another is 63 sectors per track,
 MR> but 16 tracks per cylinder.

Just a thought, but maybe this is a "safety measure" to allow for
programs that "wait too long" after checking free space and then try to
write to disk. On a multi-tasking system, it could get *really* ugly if
several programs each check, see that there's enough space, and then
try to write out their buffers.

The only other way around that sort of thing requires programs to
allocate extra sectors past the current end of file, enough to cover
potential future writes, and then release that space when they exit.
This is next to impossible to do with things like sequential files. 

--- Blue Wave/DOS v2.30
270/101