← Back to the catalog

File System Corruption

A drive can be detected normally yet show directory errors, damaged files, missing entries or file-system warnings because its metadata has become inconsistent. Similar symptoms can also be caused by unstable storage, so file-system corruption should be treated as a logical description only after the underlying device is shown to read reliably.

If the main symptom is missing folders while used-space accounting remains high, first distinguish ordinary visibility/allocation explanations from actual filesystem inconsistency — see Files Missing but Space Still Used.

Recovery decision

File system corrupted: what should you do next?

Answer one question about the current state. The result suggests the safer next step rather than diagnosing the failure.

Typical source stabilityUsually logical

Default action riskHigh

Default first actionPreserve before repair

Check my situation

This guide classifies the next recovery action from observable information. It does not diagnose hardware condition or estimate a percentage chance of recovery.

What's actually happening

File systems maintain a set of interlinked metadata: directory entries, allocation tables or bitmaps, and often a journal log of recent changes. Sudden power loss in the middle of a metadata update, read errors from a drive that's quietly starting to fail, or a software bug can leave these structures internally inconsistent — a file marked as occupying space that's also marked free, for instance, or a directory entry pointing to a location that no longer holds what it claims to.

How recoverable this really is

Logical inconsistency does not automatically mean file content is gone. If the underlying sectors are readable and enough metadata remains, recovery software can often reconstruct a useful view of directories and files. The outcome depends on which structures are damaged, whether metadata references conflict, whether data blocks have since been reused, and whether the source is actually stable.

What changes recoverability

Which metadata is damaged. A broken directory index, allocation bitmap, journal, inode tree or master file table has different consequences. Redundant or secondary metadata may allow one damaged structure to be reconstructed from another.

Whether allocation information can be trusted. If two files appear to own the same blocks, or allocated content is marked free, a repair utility may have to choose one interpretation. Recovery software can instead preserve competing evidence and copy data out without forcing the source into a single consistent state.

Whether the source is stable. Corruption caused by read errors is not purely logical. Repeated scanning or repair on a degrading HDD or SSD can turn a recoverable metadata problem into an acquisition problem.

What has already been repaired. CHKDSK, fsck, First Aid and application-specific repair tools can alter allocation, directories and orphaned objects. Their logs are useful evidence because the post-repair state may differ significantly from the original failure state.

What you can check safely

Record the exact error messages, whether the volume still mounts, which directories or files fail, and whether the symptoms are repeatable. Check for I/O errors, long stalls, disconnects or changing SMART indicators before assuming a purely logical problem. If a repair tool has already run, preserve its report or log and avoid running it again until important data is copied.

A taxonomy: which structure is actually damaged

“File system corruption” is not one failure mode, and treating it as one obscures more than it explains. Damage can localize to a specific structure, and each one produces a different symptom.

At the whole-volume level, damage to identity metadata — a boot sector or superblock — can make the volume unrecognized entirely, while damage to allocation metadata — a bitmap or equivalent — can make used space and free space disagree with reality.

At the per-object level, a damaged file record or inode can make one specific object unreadable while everything else is fine; a damaged directory index can hide files whose records and content are both intact; and a damaged extent or run map can leave data physically present but logically disordered.

Recovery-state structures fail differently again: a damaged journal can leave the volume dirty or briefly unmountable after a crash, and on APFS specifically an object map or B-tree node — several layers below anything a simple superblock repair would touch — can fail on its own. Each of these calls for a different response — see NTFS MFT, Allocation and File Reconstruction, ext4 Superblocks, Inodes, Extents and Journal and APFS Containers, Object Maps and Snapshots for how each filesystem's version of this taxonomy actually works.

Corruption is usually localized, not total

A directory index failing does not imply the file records underneath it are gone; a damaged journal does not imply the allocation bitmap is wrong; a superblock that won’t parse does not imply the data blocks it once described have been erased. The reverse also holds: directory metadata that looks entirely healthy does not guarantee the file content it points to is intact, if the referenced blocks turn out to be unreadable or have already been overwritten. Identifying which specific structure failed — rather than concluding the whole volume is “corrupted” as one undifferentiated event — is usually the difference between a targeted, largely complete recovery and an unnecessarily aggressive one.

A dirty volume is not automatically a corrupted one

A file system left dirty — flagged as needing journal replay or a consistency check after an unclean shutdown — is not the same thing as a file system whose structures are actually inconsistent, missing or unreadable. A pending journal replay is evidence about file-system state, not by itself proof of serious structural damage. The reverse caution also applies: a journal replaying successfully does not prove that every file's payload survived intact.

Why repair can discard exactly what recovery needed

Repair tools are built to make a file system internally consistent again, which is a genuinely different objective from preserving every recoverable structure along the way. Repair can rewrite trees, discard orphaned records, rebuild allocation metadata, relink files and free blocks — and a filesystem that becomes mountable after repair may no longer contain every structure that existed immediately before the repair ran. See Filesystem Journals and Crash Consistency for why even journal replay, a narrower operation than full repair, can already change what evidence survives.

The general approach

Proper recovery here works by comparing surviving file-system structures and extracting files from the most credible reconstruction rather than forcing the source into a repaired state. For important data, work from a sector-level image or another preserved copy when practical; if the storage is unstable, acquisition comes before file-system analysis.

Tools such as TestDisk can inspect or repair selected partition and boot-sector structures, while file-system-aware recovery suites such as R-Studio can scan damaged volumes and copy data out without requiring in-place repair. See the full directory of recovery software by vendor · Files Missing but Storage Space Is Still Used · Computer Won’t Boot · Recovering Encrypted Wallet Files and Keystores · Allocation Metadata, Orphaned Files and Lost Space · Filesystem Structure and Metadata Recovery Tools.