• Please review our updated Terms and Rules here

Patch program for DIR free space calculation

S

Simone2013

Experienced Member
Joined
Aug 21, 2013
Messages
120
Location
Ravenna (Italy)
Hi to all

I noticed this problem with slow XT/AT Clone with huge (for the time) hard disk in FAT16. The first DIR and similar operation involved DOS int 21h/36h for calculating free clusters... this takes AGES on this type of machine... but

I've found a solution to this SLOWness!

I've made an application to overcome this DIR wait (because NO solution is available also today)
the concept is to "fool" dos saving the "free space" / realoading it at startup (maybe with AUTOEXEC.BAT).

So DIR command take Always the same time like from the 2nd DIR onward (also 1st) and it SAVE me most of the wait! It's not a TSR so no memory waste!

DOS 3.2+ required

I've published my app (FIXDTP.EXE) on my Facebook page. If you want join: https://www.facebook.com/OlivettiProdestPC1

If you are interested PM to me.

Hope this will help!
 
Do you have a similar solution for FAT32 volumes in DOS? The FAT16 delay never really bothered me, but a 20GB partition in DOS 7 can really take some time.
 
Simone2013 said:
the concept is to "fool" dos saving the "free space" / realoading it at startup (maybe with AUTOEXEC.BAT).

So DIR command take Always the same time like from the 2nd DIR onward (also 1st) and it SAVE me most of the wait! It's not a TSR so no memory waste!
Click to expand...

My problem with this is that, if you don't save the drive table before shutting down, it is incorrect when you reload it.

Because the DIR only takes a long time the first iteration, and is fast every other time, what's wrong with just putting DIR C: in your autoexec.bat?

(Aside: It looks like you used a C printf function inside your Pascal program; do you have a link to the source of that routine?)
 
Trixter said:
My problem with this is that, if you don't save the drive table before shutting down, it is incorrect when you reload it.
Click to expand...

Yes you are right, but it involves only free clusters... I.E. Large partition with Compactflash has plenty of free space and don't change too much. Instead i must do multiple reset to test many configuration in my 8086, and every time I must wait >1 minute and when you have 3/4 partition it can be boring (also with DIR C:)! The free space can be also forced to update with /R option.

Trixter said:
(Aside: It looks like you used a C printf function inside your Pascal program; do you have a link to the source of that routine?)
Click to expand...
Strange, I used the standard writeln procedure... Formatting is done by subfunction. It's a standard Turbo Pascal 7 compiled with 8086 instruction set... Maybe constant are null terminated string?
 
Chuck(G) said:
Do you have a similar solution for FAT32 volumes in DOS? The FAT16 delay never really bothered me, but a 20GB partition in DOS 7 can really take some time.
Click to expand...

Chanches are that it can work also with DOS7 & fat32 because I used some "undocumented" int21 DOS function that should work in any version >3.2 - DOS7 and FAT32 should have a more efficient algorithm to calcolate free space also...

I know that don't work in DOSBOX for sure, but feel free to try and report here to me.
 
Simone2013 said:
Strange, I used the standard writeln procedure... Formatting is done by subfunction. It's a standard Turbo Pascal 7 compiled with 8086 instruction set... Maybe constant are null terminated string?
Click to expand...

No, you have some sort of extended error handling routine in there. Strings like "Critical disk error on drive %C" and "~Enter~ Retry ~Esc~ Cancel". Curious what that is.
 
I wonder if this will even work well with FAT32 real-mode operation. My experience is that DOS is even slow to pick up on FAT32 file creation. That is, a program creates a file and writes to it; do a DIR and the file's not there. Do a control-C reset and it suddenly appears with the next DIR. I can't help but see that this will aggravate the problem.
 
Trixter said:
No, you have some sort of extended error handling routine in there. Strings like "Critical disk error on drive %C" and "~Enter~ Retry ~Esc~ Cancel". Curious what that is.
Click to expand...

Probably is DOS unit (TPU) that I included for disk Handling, so the program is linked also with error-Handling written in... C! ;)
 
Chuck(G) said:
I wonder if this will even work well with FAT32 real-mode operation. My experience is that DOS is even slow to pick up on FAT32 file creation. That is, a program creates a file and writes to it; do a DIR and the file's not there. Do a control-C reset and it suddenly appears with the next DIR. I can't help but see that this will aggravate the problem.
Click to expand...

I didn't notice that quirk in dos FAT32... Something similar I noticed with network drive in Windows. I don't think that the program can aggravate the problem (if even work) because it involve only free space calculation. The file creation slowness can be a "forced free cluster" calculation (I noticed also in FAT16 -without my program-). So should be ininfluent, apart from incorrect free space display on DIR (i have plenty of free space in 2Gb SD card so this is not a problem!)
 
Chuck(G) said:
I wonder if this will even work well with FAT32 real-mode operation. My experience is that DOS is even slow to pick up on FAT32 file creation. That is, a program creates a file and writes to it; do a DIR and the file's not there. Do a control-C reset and it suddenly appears with the next DIR. I can't help but see that this will aggravate the problem.
Click to expand...
I only ever had that problem with the old DOS interrupts for disk reading. If you have a proper LFN support in the OS (like under win95's dos7-ish) you should try using int21/AH=71h calls as it doesn't have those problems in my experience.

You do int 21h, AH=71h and AL 4Eh and 4Fh it's not a problem. Of course, if you're on a fat32 system that lacks the support for those calls, you're pretty well shtupped as yeah, the classic int21h AH=4Eh and 4Fh it seems to miss file creation.

Though I thought if you skipped having a filesystem cache (like smartdrv) that problem went away, though it's been ages since I've dealt with that.
 
DOS 7 (essentially Win98SE DOS) using DOSLFN for CLI long file name capabilities (although presence/absence of that doesn't appear to make a difference).
 
It allows you to save the free space value to a file, manually, before turning off the computer. Then it is intended that you run the util again in autoexec.bat to load the previously-saved value into the relevant DOS data structure on bootup.

My issue with this strategy is: What happens if you forget to save before turning off the computer, and then an old value is loaded from calling the util in autoexec.bat on bootup?
 
Everyone should have an off.bat file that is run immediately before shutdown to cleanup all kinds of loose ends and whatnot and run whatever housekeeping is deemed necessary. I can remember using this type of utility as late as WIN95 and WINME.
 
I've noticed the pause for the calculation at all sorts of times, not just at startup. This solution seems incomplete ... a patch to command.com is probably required to fix it correctly.

At this point I just live with the pause, or use DOS 3.3 if I can.
 
Same here. Since I don't see the long pause when Windows is running, I suspect that really useful code is buried in a VXD.

Or just use a third-party directory listing utility that doesn't compute the free space--or can disable it. I haven't tried, for example, DIR /B (bare listing) to see if there's the same delay...
 
Stone said:
Everyone should have an off.bat file that is run immediately before shutdown to cleanup all kinds of loose ends and whatnot and run whatever housekeeping is deemed necessary.
Click to expand...

This does not help those who hang their system. I think, in this specific case, the better alternative is not to run the utility in autoexec.bat, so that the user can deem if it is safe to load the previous value or not.

Chuck(G) said:
I haven't tried, for example, DIR /B (bare listing) to see if there's the same delay...
Click to expand...

It is still there.

mbbrutman said:
I've noticed the pause for the calculation at all sorts of times, not just at startup.
Click to expand...

Whenever DOS needs to recalculate free space, the tally is performed. Some disk utilities (like defrag) can invalid the value, as can certain DOS functions (like int 25h), so DOS performs the tally again when it feels it needs it.

It's not limited to DIR, it happens whenever that value is needed. For example, if I use mTCP's FTP client before I've done my first DIR, I get the pause at first disk activity. I know the FTP client isn't doing it -- DOS is.

a patch to command.com is probably required to fix it correctly.
Click to expand...

A rewrite of how DOS caches the FAT and that value is required to fix it correctly. It's not a command-line processor thing.

At this point I just live with the pause, or use DOS 3.3 if I can.
Click to expand...

I do the same. It's 17 seconds on my XT and 55 seconds on my PCjr and since it happens mostly only once at boot, I can live with it.

Sorry for the verbosity in this reply, but I traced through DOS working out how and why this occurs when I wrote PADD so I just wanted to clear up some misconceptions.
 
You must log in or register to reply here.
Back
Top