• Please review our updated Terms and Rules here

Patch program for DIR free space calculation

A number of delete protection and unformat utilities place the extra copies of the partition table and FAT in the highest clusters making it a bit harder to figure out when to stop counting used space. Usage bitmaps would probably be the fastest method for tracking free space; it should take less time to process 8 kB of bitmap than 128 kB of FAT.
 
Do the undelete and unformat utilities actually place entries in the FAT (and, by extension, the directory?) I thought that they simply appropriated the high clusters and crossed their electronic fingers. But yes, a bitmap would be the common-sense method--but then you'd have to have another utility to check that the FAT and the bitmap agreed...
 
Do the undelete and unformat utilities actually place entries in the FAT (and, by extension, the directory?) I thought that they simply appropriated the high clusters and crossed their electronic fingers. But yes, a bitmap would be the common-sense method--but then you'd have to have another utility to check that the FAT and the bitmap agreed...

yes, would be a double check to also mantain bitmap...
maybe saving highest used cluster (and lower free cluster) can speed up Whole thing. Specially in low-fragmented HD would be lighning fast! But same problem, anyway, because we had to update those numbers by full scan!
If you need only approximately free space, higher used cluster can also be enought (we are just talking of 2 Gb of space and plenty Mb free in an XT!)

For my point of view - testing several boot & software - I only need a fake free space counter because I need to speed up my DIR's etc etc...
A Whole new filesystem in my opinion can also be a problem for much dos software, and must support (for retrogaming!) also DOS 2.0, 3.3, 4.0 ..... freedos, Windows...
 
What about SET DIRCMD=/B? It will give you the bare directory listing all the time. I think it should work in everything from DOS 2.0 and up, so if storage space is not tight, this seems to be a good solution for the slow free disk calculation issue for all.
 
What about SET DIRCMD=/B? It will give you the bare directory listing all the time. I think it should work in everything from DOS 2.0 and up, so if storage space is not tight, this seems to be a good solution for the slow free disk calculation issue for all.

yes, I know that this command can just step out of the problem! The truth is I don't like "/B" format and free space counting is happening also in other situation (like creating a new file, MSD.EXE, etc etc)
I was only thinking a "programming" solution on a not-so-hard problem....
 
Trixter, you are right, every time DOS invalidate the free space the tracing of the free space is extremely slow.
If I'm right it can be accomplished in a fraction of the time, just load FAT and count free cluster [00 00 signature] should be right. ...
I can re-write my program to use the upper method and see if is faster than DOS, like I think. This program can be launched in AUTOEXEC.BAT and will show exact free space, this time. 128kb is not a problem at boot.

I think this is a great solution. It's non-destructive and not prone to user error. I'd be happy to test if you get this working.
 
I think this is a great solution. It's non-destructive and not prone to user error. I'd be happy to test if you get this working.

I'll go for it then! :p
Thank you for your support I'll upload it when done. For now I'll support only FAT16 (because FAT32 is less used with 8086 and pure DOS).
Just some time to refresh my memory about Turbo Pascal 7 and Assembler... this command must be fast. maybe ".com" is better.

Best regard
 
I'll go for it then! :p
Thank you for your support I'll upload it when done. For now I'll support only FAT16 (because FAT32 is less used with 8086 and pure DOS).
Just some time to refresh my memory about Turbo Pascal 7 and Assembler... this command must be fast. maybe ".com" is better.

Best regard

O.k. So I am totally necroposting here but my recent thread over here has led back to this program. Did you ever update your program with the new free space counting method?
 
Back
Top