The other FSK


Eric Auer posted this on the FreeDOS mailing list, and I thought it was good to re-post it here:

Hi, I am writing this to point you to: which is yet another CHKDSK type tool by Andreas Rosenberg.

He released it in 2000 under GPL2 and cannot currently maintain it. However, it might be interesting for you to read. Originally, he wrote it for an Atari where he had lots of lost clusters. [Note: the Atari ST used FAT for storing files. -jh] The current version is made in Borland C++ 5.0, but at first glance, I do not see why it should not compile on Turbo C 2.01 :-).

WARNING: The drive access functions need fixing. Andy only uses absread() and abswrite(), but without the count = 65535 trick which is needed for disks bigger than 32MB. He also has some (disabled) assembly code for that (which would use the bigdisk trick): To fix the assembly code, add "popf" after "int 25/26" lines :-). Reason: int 25/26 are actually call far, not int!

ALTERNATIVE fix is to just use absread() and abswrite() but with the 65535 trick! I am not sure, either the count or the sector number must be 65535, and then the pointer to the BUFFER is actually used as pointer to a STRUCTURE which contains 32bit sector number and a pointer to the actual buffer. Whatever. Read the rest in RBIL IntList :-).


Not much more. Some 1500 lines of C. Only FAT12/FAT16 up to 32MB drive size unless you fix the disk driver! Also uses int 13.8 to get the drive geometry (same division by zero as in FreeDOS kernel INITDISK.C here if your BIOS erroneously reports 0 sectors per track) and fetches other BPB info from the boot sector. As a progress indicator, the number of the currently processed cluster is printed.

I personally think that FreeDOS CHKDSK (Imres version) is by now much better than FSCK. But maybe Andys FAT scanning or directory walking algorithms are faster. As usual for FreeDOS, you may enjoy the code!

Be warned that this is a disk tool which may terribly choke when it encounters unknown filesystem properties (FAT32, LFN, drives bigger than 32MB) and destroy data. However, feel free to IMPROVE IT :-).