Data Recovery Case File · Formatted & Logical Faults · Scanning and Extracting Are Different

A Complete File List Is Not Evidence That the Files Can Be Read

His enquiry contains a result that looks encouraging and reports the opposite. A drive presenting without a recognised filesystem, where he tried two independent recovery programs: "both have found all the files on the drive, but give an error" when recovering them. Finding a file and reading it are separate operations — and two tools agreeing tells him something precise about where the fault is.

The decode: what a scan reads, and what an extraction needs

What a scan actually does: reads the filesystem's structures — the records saying what files exist, what they are called, how large they are and which regions hold them. Those structures are small and occupy a defined area, and a scan that completes has read that area successfully.

What an extraction does: goes to the regions the structures point at and reads the content. That is the whole drive rather than a small region, and it is a completely different demand.

So what his result means: the structures read and the content does not. The metadata region is healthy and the surface holding the files is failing — which is precisely the opposite of the situation people assume when they see a full listing.

Why the full listing is so misleading: it looks like success. Every filename, every folder, every size — visibly present and apparently ready, which naturally reads as evidence that the data is fine and just needs writing out. It is evidence about the index only.

Why two tools agreeing is genuinely informative: independent programs failing identically eliminates the software. Neither is at fault and a third will do the same, which saves him trying one.

Why those tools cannot succeed here regardless of quality: they run through the operating system and inherit its error handling. A read that fails is retried by the system for its full timeout before the application sees anything, so extraction across a failing surface either stalls indefinitely or aborts.

What works instead: imaging with per-sector timeouts capped deliberately, difficult regions deferred rather than allowed to consume the session, and multiple passes over weak areas. Extraction then runs against the image, where the tools he already has would work perfectly, because an image does not have read errors.

What the scanning has already cost: two full-surface reads on a drive that is failing. Every scan is sustained reading across the whole medium, and a third would be the same expenditure for the same answer.

What must stop: further scanning, and any attempt to extract directly from the drive.

On the bench

Scan success was distinguished from extraction success before any conclusion — a scan reading filesystem structures occupying a small defined region, while extraction reads content across the entire surface, so a complete listing evidences only that the metadata is healthy. No further scanning was permitted, each scan constituting a full-surface read. Imaging ran write-blocked under strict per-sector timeouts with retries capped, and extraction performed against the image rather than the drive.

The outcome

Scan success separated from extraction success, no further scanning permitted, and extraction performed against a capped-timeout image. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: a full file list is evidence about your index, not your files. Scanning reads structures in a small region; extraction reads content across the whole surface — and yours is failing at the second.

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.