Posting to this group in 2012 is akin to shouting into the wind, but
what the heck, I'll give it a shot anyway. I'm working on a hobby
program for DOS that reads FAT12/FAT16 directly, and I've noticed that
sometimes DOS returns incorrect information in int 21 subfunc 36h
which is "get free disk space". For reference:
Return:
AX = FFFFh if invalid drive
else
AX = sectors per cluster
BX = number of free clusters
CX = bytes per sector
DX = total clusters on drive
I have used this function to get BX (number of free clusters), then
read the FAT12 or FAT16 directly myself with my own routines and found
that DOS sometimes reports 1 or 2 more free clusters than are actually
marked as such in the FAT. I've gone over a FAT16 hex dump with my
own eyes, cluster by cluster, to make sure my routines are working
properly -- they are. So DOS (in my case, IBM PC DOS 2000 which is PC
DOS 7.03 IIRC) is wrong in this case.
Has anyone else seen this and/or might know what is causing it?
In comp.os.msdos.programmer message <93a63172-c998-4200-b7e7-8a3b62a3740
e...@c17g2000yqe.googlegroups.com>, Wed, 17 Oct 2012 13:58:30, Jim Leonard
<mobyga...@gmail.com> posted:
>Posting to this group in 2012 is akin to shouting into the wind, but
>what the heck, I'll give it a shot anyway. I'm working on a hobby
>program for DOS that reads FAT12/FAT16 directly, and I've noticed that
>sometimes DOS returns incorrect information in int 21 subfunc 36h
>which is "get free disk space". For reference:
>Return:
>AX = FFFFh if invalid drive
>else
>AX = sectors per cluster
>BX = number of free clusters
>CX = bytes per sector
>DX = total clusters on drive
>I have used this function to get BX (number of free clusters), then
>read the FAT12 or FAT16 directly myself with my own routines and found
>that DOS sometimes reports 1 or 2 more free clusters than are actually
>marked as such in the FAT. I've gone over a FAT16 hex dump with my
>own eyes, cluster by cluster, to make sure my routines are working
>properly -- they are. So DOS (in my case, IBM PC DOS 2000 which is PC
>DOS 7.03 IIRC) is wrong in this case.
>Has anyone else seen this and/or might know what is causing it?
Could it be that your own code is reading the FAT from the actual
magnetic medium, and Int21/36 is reading a copy of the FAT buffered in
RAM that has not yet been fully written to the actual disc? (or /vice
versa/??)
-- (c) John Stockton, nr London, UK. For Mail, see Home Page. Turnpike, WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.
<reply1...@merlyn.demon.co.uk.invalid> wrote:
> Could it be that your own code is reading the FAT from the actual
> magnetic medium, and Int21/36 is reading a copy of the FAT buffered in
> RAM that has not yet been fully written to the actual disc? (or /vice
> versa/??)
No, as I get the same results from a clean boot.
I don't think DOS caches FAT writes, only reads. If it cached FAT
writes, then you couldn't power a machine off at the DOS prompt
without losing data.
Jim Leonard <mobyga...@gmail.com> wrote:
> I have used this function to get BX (number of free clusters), then
> read the FAT12 or FAT16 directly myself with my own routines and found
> that DOS sometimes reports 1 or 2 more free clusters than are actually
> marked as such in the FAT. I've gone over a FAT16 hex dump with my
> own eyes, cluster by cluster, to make sure my routines are working
> properly -- they are. So DOS (in my case, IBM PC DOS 2000 which is PC
> DOS 7.03 IIRC) is wrong in this case.
> Has anyone else seen this and/or might know what is causing it?
Are you sure the disk integrity is OK?
Have you tried different DOS? Preferrably MS-DOS?
Post the link to the disk image if possible.
On Oct 19, 10:39 am, JJ <jaejunks_at@_googlemail_dot._com> wrote:
> Are you sure the disk integrity is OK?
All the partitions I've tested with pass a CHKDSK and NDD without any
issues.
> Have you tried different DOS? Preferrably MS-DOS?
I have not! Whoops! I will test with a few different DOSes to see if
I can reproduce the results.
> Post the link to the disk image if possible.
Image of what? A bootable disk of the DOS I'm using, or the hard disk/
partition with the filesystem I'm testing against? (if the latter,
what disk image format and/or tool?)
> Posting to this group in 2012 is akin to shouting into the wind, but
> what the heck, I'll give it a shot anyway. I'm working on a hobby
> program for DOS that reads FAT12/FAT16 directly, and I've noticed that
> sometimes DOS returns incorrect information in int 21 subfunc 36h
> which is "get free disk space". For reference:
> Return:
> AX = FFFFh if invalid drive
> else
> AX = sectors per cluster
> BX = number of free clusters
> CX = bytes per sector
> DX = total clusters on drive
> I have used this function to get BX (number of free clusters), then
> read the FAT12 or FAT16 directly myself with my own routines and found
> that DOS sometimes reports 1 or 2 more free clusters than are actually
> marked as such in the FAT. I've gone over a FAT16 hex dump with my
> own eyes, cluster by cluster, to make sure my routines are working
> properly -- they are. So DOS (in my case, IBM PC DOS 2000 which is PC
> DOS 7.03 IIRC) is wrong in this case.
> Has anyone else seen this and/or might know what is causing it?
Sorry, no.
I've not called it directly from assembly. It's very possible I called it
indirectly via a DJGPP C function.
I can make some basic (or wild) guesses, that you could probably make too.
Here are my basic guesses. I doubt they'll help all that much:
1) one of the other four issues listed in RBIL's description
2) allocation not flushed to disk
3) bug in your math calculations
4) bug in your version of DOS
The first two of the four RBIL issues seem plausible that they could cause
your issue.
The last RBIL issue mentions FAT32. The issue seems unrelated, but it makes
me wonder if your filesystem is actually FAT16. Could it be FAT32? From
Wikipedia's FAT page, there are a large number of variations: FAT16B,
FAT16+, FATX16, FAT32, FAT32X, FAT32+, FATX32, exFAT.
For possible math bugs, I'm thinking something like:
adc instead of add, CF is set or not cleared via CLC
sbb instead of sub, CF is set or not cleared via CLC
dx is not cleared for 16/32-bit div or mul or imul
Jim Leonard <mobyga...@gmail.com> wrote:
>> Post the link to the disk image if possible.
> Image of what? A bootable disk of the DOS I'm using, or the hard disk/
> partition with the filesystem I'm testing against? (if the latter,
> what disk image format and/or tool?)
A copy of the drive where the test fails. If a floppy drive share the same issue, use it instead, since it's smaller.
>> Could it be that your own code is reading the FAT from the actual
>> magnetic medium, and Int21/36 is reading a copy of the FAT buffered in
>> RAM that has not yet been fully written to the actual disc? (or /vice
>> versa/??)
> No, as I get the same results from a clean boot.
> I don't think DOS caches FAT writes, only reads. If it cached FAT
> writes, then you couldn't power a machine off at the DOS prompt
> without losing data.
Writes are cached though, as you probably know, when using SMARTDRIVE (or similar disk cache).
Smartdrive does watch for user initiated shutdown (the 3-finger salute) and will flush its buffers before letting the shutdown finish (but of course a brutal reset or power-off may prevent this to happen).
Are you using smartdrive along with your puzzling experiments ?
On Oct 19, 6:41 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> 1) one of the other four issues listed in RBIL's description
> 2) allocation not flushed to disk
> 3) bug in your math calculations
> 4) bug in your version of DOS
(For some reason, my explanation didn't come through, so I'll post it
again.)
It turned out to be a combination of #1, #3, and #4: I was
misinterpreting the number of clusters returned in BX as "maximum
cluster" -- turns out it is a "count of clusters" value instead. So
my math was off by 1 or 2 in some cases. I was using 2..NC-1 as my
cluster range, when I should have been using 2..NC+1. The Microsoft
FAT whitepaper from 1999 was very helpful in clearing that up.
Also, for times when my math WAS correct, different versions of DOS
were behaving differently, and a few trashed BP when I wasn't looking.
Since I am mixing asm with a HLL, I return results via SS:BP; once BP
was trashed, I returned results into random parts of memory. I now
preserve all registers I rely on so this is no longer a problem.
Jim Leonard <mobyga...@gmail.com> crivait news:58949ebd-c7b0-
4f84-b58a-84ee1067e...@s12g2000vbw.googlegroups.com:
> On Oct 23, 11:32 am, NimbUs <nim...@XXX.invalid> wrote:
>> Are you using smartdrive along with your puzzling experiments
?
> No, which is why I mentioned that DOS doesn't do that.
OK, just wanted to double check with you. I'll have a look at function 36h in DOS source code to see whether it flushes the FAT before making its calculations. Did you mention which DOS version you have experienced this problem with ?
