Some senseless babbling from Leonard Erickson to Mike Ruskai
on 10-23-99  18:49 about HPFS info quest...

 -=> 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.

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

Programs that check free space do so for the human user's utility (e.g.
which drive to install something on).

The write attempt itself is where the program learns whether or not there's
any space left, provided it checks the success of the operation (which all
competent programmers make sure of).

Even if the program doesn't check, nothing bad can happen.  The program
will inevitably end up using an OS facility to do the writing, which will
simply fail if there's no space available to write to.

The worst case is that the programs which don't check the success of their
write operations break.

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

It's not even difficult, actually.  HPFS has a facility for reserving more
space than needed, to accomodate future file expansion.  The reported size
of the file will be what it's actually using, while there will be extra
sectors marked as used that the file owns.

Regardless, you're painting a picture of disk operations that just isn't
accurate.  It's ultimately the file system driver which has the ability to
screw things up when a write is requested, with no space to write to.  An
application can't cause any problems, outside of its own malfunction,
should it fail to account for a write failure.

And of course, this doesn't have anything to do with the 4096 sectors in
question, which aren't reserved for any files, and can't be used for
storing data (when the drive is full, not counting those 4096 sectors, all
future write attempts fail).

Mike Ruskai
thannymeister@yahoo.com


... Hello, I'd like an argument please.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
500/3