Data Recovery Case File · Cameras, Drones & Cards · Reading Can Involve Writing
The Application Was Probably Writing to the Card Too
His enquiry places the failure at a moment that sounds harmless. A card that "corrupted when I was trying to download images onto" an editing application, and has not been readable since. Importing sounds like pure reading and frequently is not — many applications write to a card during an import, and an interruption during one of those writes damages structures exactly as any other interrupted write would.
| Media | SD card — filesystem damaged during an import operation into editing software; images not accessible since |
| Reported situation | Card in normal use holding photographic content · import into editing software attempted · card becoming unreadable during that operation · images not accessible since · contents required |
| Fault class | Filesystem damage from an interrupted write during import — application-side writing and possible post-import deletion to be established |
| Equipment used | Import settings and post-import deletion behaviour established before assessment · card removed from use · imaged write-blocked under strict timeouts · structures reconstructed on the image from surviving copies · media validated by rendering |
The decode: what an import actually does to a card
What people assume: that an import reads images off the card and writes them to the computer, leaving the card untouched. That is what it looks like, and for some applications it is what happens.
What many applications also do: write to the card. They record which images have been imported so they can be skipped next time. They generate previews and store them alongside. They create catalogue or index files in a folder of their own. Some are configured by default to delete the originals once the import completes, which is a write of the most consequential kind.
Why that changes the reading of his case: if the application was writing, then a failure during the import is an interrupted write — and interrupted writes to a filesystem leave structures half-updated and internally inconsistent. That is the ordinary way cards become unreadable, and it explains a failure that otherwise looks like coincidence.
What to establish, and it costs nothing: whether the import was set to delete after copying, and whether the software writes previews or catalogues to source media. Both are settings, both are frequently on by default, and the answers change what is likely to be found.
Why the deletion setting is the urgent one: if it was enabled and the import failed partway, some images may have been marked as removed before the failure. Those are still physically present — deletion removes a reference rather than content — but it means the structures were being actively rewritten at the moment things went wrong.
What the position is regardless: the card presented and was being read, so the medium works. The damage is to the description rather than to the images, and reconstruction from surviving copies of the filesystem structures is the routine approach.
What must not happen: no repair, no format, and no putting the card back into the camera. A camera meeting a filesystem it cannot interpret may offer to prepare the card, and some do it without asking.
The habit worth forming: copy files off a card manually before importing anything, and turn off any option to delete after import. The card should be the last copy to be cleared, not the first.
On the bench
Import settings and post-import deletion behaviour were established before assessment — editing applications frequently writing to source media during import, recording which images have been taken, generating previews, creating catalogue files, and in some configurations deleting originals on completion, so a failure during import is an interrupted write rather than a coincidence. The card was imaged write-blocked under strict timeouts, structures reconstructed on the image from surviving copies, and media validated by rendering.
The outcome
The import behaviour established first, the card imaged under strict timeouts and structures rebuilt from their surviving copies. 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: importing is not always read-only. Many applications write to the card as they go — recording what has been taken, generating previews, sometimes deleting originals on completion — so a failure during an import is an interrupted write, which is the ordinary way filesystems break.
Card that failed during an import
Check whether your software was set to delete originals after importing, and whether it writes previews or catalogue files to source media — both are common defaults and both mean the import wasn't the read-only operation it looked like. That matters because a failure during a write leaves filesystem structures half-updated, which is the ordinary way cards become unreadable, and it explains a failure that otherwise seems like coincidence. Your card presented and was being read, so the medium works and the damage is to the description rather than the images. Don't put it back in the camera, which may offer to prepare it. In future, copy manually first.
Keep it out of the camera — call Oxford Data Recovery on 01865 593000; import behaviour established first, imaged write-blocked under strict timeouts, structures rebuilt from their surviving copies.
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.