Data Recovery Case File · Formatted & Logical Faults · The Master File Table
The Master File Table, given its own page: what NTFS's grand catalogue actually is, why chkdsk concedes defeat on it — and how her folder structure came back intact, rebuilt from the table's own remnants on an image
Her enquiry arrived better-researched than most trade referrals. A four-year-old Seagate 2TB Expansion throwing "disk structure is corrupted and unreadable" out of the blue, no physical damage; then her own investigation: "I think I've established the problem is with the Master File Table, as the files still seem to be on there from looking at recovery software — and chkdsk gives me the message 'Windows cannot recover master file table.'" And the precise question that deserves a precise answer: "are you able to fix or repair the MFT such that my files can be recovered with the original folder structure intact?" Yes — and this page explains it properly: what the MFT actually is, why her diagnosis is almost certainly right, why chkdsk's surrender is the expected outcome rather than the final word, and how professional reconstruction rebuilds the table from its own surviving remnants — names, tree and all — on an image where nothing can be made worse. Her email-first contact preference was honoured throughout, and the pop-in she offered gladly taken.
| Media | Seagate Expansion 2TB external (~4 years old) — sudden "disk structure corrupted and unreadable"; no physical trauma reported |
| Reported situation | Owner-diagnosed MFT damage · recovery software shows files present · chkdsk reports "Windows cannot recover master file table" · original folder structure explicitly required |
| Fault class | NTFS Master File Table corruption on responsive hardware — catalogue damage over intact data; structure-preserving reconstruction indicated, chkdsk-style repair contraindicated |
| Equipment used | Write-blocked imaging (DeepSpar USB Stabilizer 10Gb) · MFT and MFT-mirror analysis and reconstruction on the image · OSForensics cross-verification of the rebuilt tree · structure-intact delivery |
The decode: the grand catalogue, the surrender message, and the road to an intact tree
What the Master File Table is: NTFS — the Windows filesystem her drive uses — keeps its entire world in one central ledger: the Master File Table, a record for every file and folder on the volume — its name, its place in the tree, its dates, and the map of where its data physically lives. It is the volume's grand catalogue; the files themselves are the stacks. Damage the catalogue and the stacks stand whole but unfindable — which is exactly the picture her investigation assembled: recovery software (which reads the disk beneath the catalogue) sees the files present, while Windows (which lives by the catalogue) declares the structure unreadable. Her diagnosis fits every symptom, and it earns the credit hers by right: she localised the fault to precisely the layer it lives on.
Why chkdsk surrenders — and why that's not the verdict: "Windows cannot recover master file table" is chkdsk hitting the boundary of its design. Chkdsk repairs a volume by the MFT — cross-checking records, mending inconsistencies between the catalogue and the disk. When the MFT itself is too damaged to serve as the reference (and its built-in partial mirror can't fill the gap), chkdsk has no ground to stand on and says so. That's a tool honestly declaring its limit — not a statement about the data, and emphatically not a reason to let any utility "fix" further, since aggressive repair on a broken MFT is precisely how intact files end up orphaned into anonymous fragments. Professional reconstruction works from the opposite direction: not repairing the live volume by its broken ledger, but rebuilding the ledger from everything that survives — the MFT's own records are individually robust and largely intact even when the table as a whole won't parse; the mirror contributes its portion; and record by record, the catalogue is reassembled on an image, names, folders, hierarchy and all. Which answers her precise question precisely: yes — because the structure she wants preserved is recorded redundantly in the very remnants the rebuild reads.
On the bench
The drive — dropped in as offered — was imaged write-blocked behind the DeepSpar USB Stabilizer 10Gb, and the reconstruction ran entirely on the copy: the damaged MFT parsed record by record, the mirror consulted for its portion, and the catalogue reassembled until the volume's original tree stood complete — her folders under their own names, in their own places, exactly as the question required. OSForensics cross-verified the rebuilt structure against the raw records and confirmed the files opened. The delivery was the tree itself, intact — not a flat heap of recovered files, but the drive as she'd organised it — with every update arriving, as requested, by email.
The outcome
The MFT reconstructed on the image and the volume delivered with its original folder structure fully intact — her question answered in the affirmative, in kind. Free assessment, one fixed written figure including VAT, no recovery, no fee. For every owner who's chased the same trail: the MFT is NTFS's grand catalogue, its corruption hides files without harming them, chkdsk's surrender is a tool reaching its honest limit — and the road to an intact tree is reconstruction from the table's own remnants, on an image, never further repair against the live volume. She did the diagnosis; the bench did the rebuild; the structure did survive.
Chkdsk says it cannot recover the Master File Table
Stop there — that message is chkdsk honestly conceding its design limit, not a verdict on your files, which recovery software has probably already shown you are still present. Don't escalate to stronger repair utilities: aggressive fixes against a broken MFT are how intact files become orphaned, nameless fragments. The structure you care about — names, folders, hierarchy — is recorded redundantly in the MFT's own surviving records and its mirror, and professional reconstruction rebuilds the catalogue from those remnants on a write-blocked image, preserving the tree. So image first, rebuild on the copy, and insist on structure-intact delivery — a recovery that returns your organisation, not just your bytes.
The catalogue can be rebuilt from its own remnants — call Edinburgh Data Recovery on 0131 202 0491; imaged, reconstructed structure-intact, verified — one written figure, no recovery, no fee.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.