DOS ain't dead

Hi Folks,
I truly wish there was a member in Toronto Canada, because I am having a
few issues after a move.
Will only ask about one, hoping there is well something I can do.
Ran chkdsk on a partition of one of my hard drives. I use the dos 7.1
package, and as my floppy drive is a touch questionable, used it instead of
scandisk.
Will spare you the details of how the problem likely started, but is there
a way to recover from a disk full of file0000chk items?
Feeling a bit scared,
Karen

> I truly wish there was a member in Toronto Canada, because I am having a
> few issues after a move.
> Will only ask about one, hoping there is well something I can do.
> Ran chkdsk on a partition of one of my hard drives. I use the dos 7.1
> package, and as my floppy drive is a touch questionable, used it instead of
>
> scandisk.
> Will spare you the details of how the problem likely started, but is there
>
> a way to recover from a disk full of file0000chk items?

You mean other than restoring a backup? If only remotely possible, first make an image of a filesystem (e.g. using a linux CD and DD and some USB-IDE or USB-sata tool) before running disk checkers, specially if you think something might be wrong.

Anyway, such files are groups of clusters that scandisk couldn't attach to a valid entry in a directory anymore, so it saved them as files. It could be deleted garbage, it could be your actual files, depending on what was actually wrong with your disk.

Probably the filesystem not really recoverable anymore to its old state, but you could try to save as many files that you recognize (either that are still there, or that are in the file###chk files)

And much depends on what type of files they originally were, how large each file originally was, and how fragmented the diskette originally was.

On 1.44mb diskettes, files are usually allocated space in multiples of 512 bytes (one 512-byte sector per cluster; other disk formats may be different). Files equal to or smaller than this will have been contained in one cluster, and will therefore be fully recoverable. Original files larger than this will have been contained in multiple clusters, perhaps discontinuous, and they might or might not have been left fragmented by CHKDSK's recovery process.

Text/ASCII files will be easiest to reconstruct, as they are human readable -- just import the segments into a text editor... and save onto a different disk! There may be "junk" at the end of the final cluster of any type file "fixed" by CHKDSK's recovery -- if text/ASCII, just delete it in the editor; if binary, it *might* be ignored.

If you don't want to try to identify a binary file manually (using a hexadecimal viewer), a great, up-to-date, file-identification tool is TriD, written and maintained by Marco Pontello:

http://mark0.net/soft-trid-e.html

Unlike other file-id utilities, the identification patterns used by TriD are contained in a separate data file, which is extensible and is updated on an ongoing basis (often weekly) -- the latest (2017-Dec-11) as of this posting contains definitions for an amazing 9,428 different file types. It has an optional command-line switch to automatically correct filename extensions, which you might want to use for the FILExxxx.CHK files.

The only catch is that TriD is a Win32 command-line executable that will require the HX runtime to run under pure DOS.

TriD won't be totally perfect in it's assessment of some .CHK files. Since text/ASCII files don't usually have standardized headers, it won't be able to accurately identify these (but you can easily do that manually). Also, .COM executables will most easily be identified if they start with a jump instruction (since they don't contain headers either). Finally, in the case of fragmented binary files, TRID will generally only be able to accurately identify the first chunk (where the header exists).

Hope that helps. Good luck....

- Doug B.

Just to add one another good tool: Testdisk and Qphotorec It can well recover various multimedia files where other undelete tools failed but after disk was processed by scandisk/chkdsk there's not much hope to glue the mess other way than manually :(

---
DOS gives me freedom to unlimited HW access.