re: Coming soon to your mailbox (part 2) (FD-defrag based CHKDSK)

Hi Imre,
cool to read that actually something compiled has escaped your "99% complete code base
for defrag" :-)). I recommend that you download and have a look at dosfsck of DOSFSTOOLS
for Linux: The source code package contains some test data as well, which you can use
with your tool for further tests.

By the way, I am still looking for somebody to provide me the DISK access functions for
my DOS (djgpp, due to high amount of RAM needed) port of dosfsck (which can do FAT12/16/32).
I have posted some useful code snippets short after my "DOSFSCK for DOS" announcement mail,
but not made it to put things together yet.

Some blatant AD: My undelete tool can DIR (displays both existing and deleted files, as you
may imagine :-)) on an image file as well as on a real disk. Using an image file is the
default for the Linux version, while the DOS version defaults to using the current drive as
data source. However, you can easily recompile it to use image files in DOS as well. If there
is interest for it on the list, I can either compile a version that uses test.img or a version
that uses an image given as command line option. By the way, undelete compiles with Turbo C.

Second blatant AD: My DOS port of DOSFSCK (read above) can print the list of files checked as
well, and it works on disk images. As said, it does - alas - not yet work on actual disks.

I hope you will release your CHKDSK soon. Meanwhile, I suggest an addition: Would you be able
to add the possibility to sort directories to it? George Bell has been looking for such a tool,
and CSAP does not run stable.

PS: Would be nice if your CHKDSK could do some verbose logging, so that the user would for
example know the content of the remaining fragments of a long file name (where your CHKDSK
will strip the name to the short version if a fragment is broken) and things like that.
The log should be written to RAM first (possibly with forced pause if the log buffer runs
full) and/or written to a file on another drive. It should be possible to "turn it off",
in which case it would only scroll on the screen and will not be stored.

PPS: You could - in the long term - use a "nonbuffered" switch in your processing system to
allow checking of FAT32 (for example in combination with a disk cache) without running out
of RAM. For those who have lots of RAM and at least a 386, I recommend running [see blatant
AD] DOSFSCK in the djgpp port. Uhm. Well. Any volunteers to give DISK access to it? As said,
my port is currently limited to image files.

Cheers, Eric