Data Recovery Case File · Solid State & Flash · The Inverse of the Usual
The Catalogue Is Perfect and the Contents Are Damaged
This enquiry describes the opposite of nearly every case in this archive. A photographer's external solid-state drive holding around 800GB: "the drive appears to have corrupted, and whilst she can see the files themselves, the images within those files don't actually render. It's not a processing issue." Normally the index is damaged and the files are intact. Here the index is working perfectly and the file contents are not — which is a different fault, with a different cause and a much more urgent instruction attached.
| Media | External solid-state drive holding approximately 800GB of professional photographic work — filesystem intact and fully listing, file contents failing to render |
| Reported situation | Drive mounting normally · all files visible with names and sizes · image contents failing to render when opened · behaviour not attributable to application processing · approximately 800GB of professional work held |
| Fault class | Data-area corruption with filesystem structures intact — uncorrectable read errors or interrupted writes within file content; progression likely |
| Equipment used | Drive removed from use immediately · failure distribution mapped by date and folder before any conclusion · imaged write-blocked under per-block timeouts with marginal blocks re-read across passes · partial-file integrity assessed per image · alternative sources identified in parallel |
The decode: what damages content without touching the index
Why this is the reverse of the usual: filing structures are small, written constantly, and concentrated in specific regions — which is why they are usually what breaks. File content is large and spread across the whole device. For the index to be perfect while contents are damaged, something has affected the data area broadly while leaving the small structural regions alone.
What does that on solid-state media: most commonly, blocks returning data the controller's error correction can no longer fix. Flash stores information as trapped charge, and as cells drift the correction absorbs it — until it cannot, at which point the block returns wrong data rather than no data. That affects wherever the affected cells happen to be, which on a drive holding 800GB of images means image content rather than the comparatively tiny structural regions.
Why the files still list perfectly: the filesystem records names, sizes, dates and locations. None of that requires reading the file contents, so an index can describe files flawlessly while every one of them is unreadable. A complete listing is not evidence of a healthy drive.
The diagnostic question worth answering immediately: do all files fail, or a subset? A pattern by date or folder is highly informative — it indicates when the problem started and how far it has spread, and if older material renders while recent work does not, that suggests something affecting writes rather than storage. If everything fails uniformly, that points at a device-level condition.
The second question: do the files fail completely, or do thumbnails render while full images do not? Thumbnails come from a small preview embedded near the start of each file, so a preview appearing means the opening portion of the file is intact and the damage lies beyond it — which is a partial-file condition rather than total loss, and some images may be substantially recoverable.
Why this is urgent rather than merely bad: whatever is degrading is continuing. Files that partly render today may not tomorrow. The drive should come out of use immediately and be imaged, with marginal blocks read repeatedly across multiple passes — a block sitting close to the correction threshold frequently succeeds on a later attempt.
What to check in parallel, given this is professional work: the original camera cards, any delivered client galleries, any cloud upload, and any second copy made during an edit. An 800GB working drive is often not the only place images have been.
On the bench
The drive was removed from use immediately, the condition being progressive and files that partly render today failing outright later. Failure distribution was mapped by date and folder before any conclusion — a pattern indicating when the problem began and how far it had spread, and uniform failure pointing instead at a device-level condition. Imaging ran write-blocked under per-block timeouts with marginal blocks re-read across passes, partial-file integrity was assessed per image, and alternative sources identified in parallel.
The outcome
The drive taken out of use, the failure distribution mapped and the contents imaged with marginal blocks re-read across passes. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: this is the reverse of the usual failure. Filing structures are small and concentrated, so they normally break first — here they are perfect while the data area is damaged, which on solid-state media usually means blocks returning data the error correction can no longer fix. A complete file listing is not evidence of a healthy drive.
Files that list correctly but won't open
Stop using the drive today and get it captured, because whatever is degrading is continuing and files that partly render now may not later. Worth understanding that this is the reverse of the usual failure: filing structures are small and concentrated, so they're normally what breaks, and the fact that yours lists everything perfectly means the index is fine while the data area is damaged. On solid-state media that usually means blocks returning data the error correction can no longer fix. Two things worth checking: whether all files fail or a subset, since a pattern by date shows when it started; and whether thumbnails render while full images don't, which means the opening portion of each file is intact and the damage lies beyond it.
Stop using it now — call Guildford Data Recovery on 01483 901310; failure distribution mapped by date and folder, imaged under per-block timeouts with marginal blocks re-read across passes.
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.