chkdsk vs fsck: Same Job, Same Danger, and When Neither Should Be Run

chkdsk and fsck are the same tool wearing different platform badges. Both walk the filesystem's bookkeeping, find inconsistencies, and repair them.

Neither one repairs your files. That sentence is the whole article, and almost every guide on the subject leaves it out.

What they actually operate on

A filesystem is a catalogue: which blocks belong to which file, where each directory starts, what is free. Your data sits elsewhere, in the blocks the catalogue points at.

These tools repair the catalogue. They make it internally consistent so the volume mounts and behaves. When they meet a reference they cannot reconcile, consistency wins: the entry may be moved to a lost-and-found area under a numbered name, or dropped.

That is not a bug. It is the job. A tool asked to produce a consistent filesystem will produce one, and consistency sometimes costs an entry.

The cabinets are the filesystem. The books are your data, and they are not in this photograph. Repairing a catalogue that points at a missing book means removing the card, which is exactly what these tools do when they cannot reconcile an entry.

The differences that matter in practice

chkdsk targets NTFS and FAT. It runs from Windows, often scheduling itself for the next boot when the volume is in use.

fsck is a dispatcher: it looks at the filesystem type and calls the right checker, e2fsck for ext4, fsck.xfs for XFS, and so on. The behaviour and the options therefore differ by filesystem, not just by platform.

Both refuse to repair a mounted read-write volume, and that refusal is protection. Two writers disagreeing about the same structures is how a small problem becomes a large one.

When they are the right tool

After a power cut, a forced shutdown, or an unclean unmount, on hardware that is otherwise healthy. That is routine, it is what these tools exist for, and it is safe.

When they are the wrong tool, and this is the part that costs people their data

If the drive is physically failing, do not run them.

Two reasons, both concrete:

1. A repair is thousands of reads and writes. A drive that is dying may not survive them, and each operation is another chance for it to stop responding for good.
2. Repair means writing. Reconciling a damaged structure can overwrite the exact sectors a recovery tool would have read. You can lose recoverable data by trying to repair.

The warning signs are not subtle: clicking, grinding, repeated spin-up, disappearing and reappearing in the device list, read errors climbing while you watch.

The order that protects you

1. Stop. If the drive sounds mechanical, power it down. Minutes cost data.
2. Image it block by block onto healthy storage. A partial image is worth more than a repaired drive that died during the repair.
3. Run the repair on the copy, never on the original.
4. Recover from the copy if the repair discards things you needed.

On healthy hardware, steps 1 and 2 are unnecessary and step 3 is just Tuesday. The whole skill is telling those two situations apart before you type the command, and the tools themselves will not tell you which one you are in.

The honest limit of this page

We cannot tell you whether your drive is dying from here. SMART data helps and is not conclusive, because controller failure produces no gradual signal. The sounds are a better indicator than any software reading, and a drive can also fail silently with none.

When the data matters more than the drive, image first. That single habit makes every other decision on this page recoverable, and it is the only advice here that costs nothing to follow when it turns out to be unnecessary.