Diagnosing FAT Corruption on FreeDOS Without Making Recovery Worse

Cross-linked files, lost clusters, impossible free-space counts, and directory loops can all indicate FAT damage, but repeated repair attempts on failing media can quietly convert recoverable data into consistent-looking but incomplete data. Make a raw image first and work on a copy, not the original media.

What “cross-linked” and “lost clusters” actually mean

A cross-linked file occurs when two or more directory entries claim ownership of the same cluster in the File Allocation Table — reading either file may return data that actually belongs to the other. A lost cluster is the opposite problem: the FAT shows a cluster chain marked in-use, but no directory entry anywhere on the disk actually references it, typically because a file’s directory entry was removed or corrupted while its data clusters remained marked allocated. CHKDSK’s /F flag, when it finds lost clusters, writes each orphaned chain out to a new file named FILEnnnn.CHK in the root directory — preserving the data rather than discarding it, but leaving you to manually figure out which recovered .CHK file corresponds to which original file.

Ruling out hardware before assuming filesystem damage

Check cabling, power stability, BIOS drive geometry settings, and actual read-error counts before assuming the FAT structure itself is what’s damaged — a wrong CHS-to-LBA geometry translation, or genuinely failing media throwing read errors, can produce symptoms that look identical to filesystem-level corruption but have a completely different root cause and a completely different fix.

Running the checker in report-only mode first

Run the filesystem checker without the /F repair flag first wherever the specific tool supports a report-only mode, and save its full output before allowing any writes. Understanding exactly which specific inconsistencies it found, and what it proposes to do about each one, matters more than getting to a clean result quickly — since /F’s repairs are not generally reversible once applied.

Recovering irreplaceable data before letting the repair proceed

If specific files on the volume are irreplaceable, copy them off (from the image, not the live disk) before allowing /F to free lost chains or truncate directory entries — once a repair tool has “fixed” a lost-cluster situation by writing it out as a generic .CHK file or discarding it entirely, any structure or filename information that could have helped identify the original file is generally gone for good.

Confirming the fix without assuming file contents survived

After repair, compare file hashes where you have a prior reference and actually exercise the affected applications, then move data off suspect media entirely rather than continuing to trust it. A clean final CHKDSK pass proves the filesystem’s own structure is now internally consistent — it does not prove that every file’s actual contents survived the corruption and repair process intact, which is a separate question you still need to verify directly.

Why CHKDSK specifically, rather than a later, fancier tool

On genuine MS-DOS, Microsoft replaced CHKDSK’s default role with the considerably more capable SCANDISK starting in MS-DOS 6.2 — SCANDISK added physical surface scanning for bad clusters, could repair cross-linked files (which plain CHKDSK could only report, not fix), and offered a friendlier interactive interface. FreeDOS’s own CHKDSK package is closer in scope to the original, simpler CHKDSK behavior than to SCANDISK’s fuller feature set, which matters directly for this diagnosis: don’t assume FreeDOS’s checker will repair every category of damage a SCANDISK-era guide might describe, and treat cross-linked-file reports specifically as something you may need to resolve manually rather than expecting an automatic fix.

Related:

Sources: