Data Recovery Case File · Trust, Practice & Honest Limits · A Workflow's Own Safeguard
The File She Is Holding Was Made for Exactly This Moment
Her enquiry asks whether anybody can confirm what happened, while describing the tool that confirms it. Video files missing after an offload from a card, where "I have a hash list file listing the files that are missing. This file is made as a part of the" cloning process. That manifest records every file and a checksum of its contents at the moment they were read — which means she can establish exactly what is missing and whether what remains is intact, without anybody's software.
| Media | Hard drive holding video content offloaded from camera media — files absent from the destination; verification manifest generated during offload and retained |
| Reported situation | Video files transferred from camera media to a hard drive using professional offload software · verification manifest generated as part of that process · files subsequently found missing at the destination · drive corruption suspected · manifest retained by the owner |
| Fault class | To be determined by verification — incomplete transfer, subsequent deletion, or destination corruption, all distinguishable from the retained manifest |
| Equipment used | Retained manifest verified against the destination before any recovery assumption · missing entries distinguished from failing entries · destination drive health assessed independently by self-reported attributes · imaged write-blocked where content proved absent rather than corrupted |
The decode: what the manifest is, and what it settles
What professional offload software generates: a manifest listing every file transferred, together with a checksum calculated from its contents. It exists because copying media from a card is the one moment where an error is unrecoverable — the card gets reused, and a file that did not arrive is simply gone.
What a checksum lets her do: verify. Recalculating it from the file at the destination and comparing against the recorded value proves whether the content is byte-for-byte what was read from the card — not merely present, not merely the right size, but identical.
Why that answers her question directly: she asks whether anybody can confirm something has happened. Verification against the manifest confirms it precisely, file by file, and the tools that do it are the same ones that made the manifest.
What the three possible results mean, and they are not alike.
Files listed and absent: either the transfer never completed for those files, or something removed them afterwards. That is a deletion question, and the drive may be healthy.
Files present and failing their checksum: the content has changed since it was written. That points at the destination corrupting data, which is a drive question and a serious one.
Files present and passing: nothing is wrong with those, whatever else is true. Which is worth knowing, because it bounds the problem.
Why that distinction decides everything that follows: a deletion is recovered from the destination; corruption means the destination cannot be trusted and everything on it needs verifying before anything else is done. Those are opposite responses, and the manifest is what separates them.
What to do before anything else: stop writing to that drive, and check whether the card has been reused. If the original media still holds the footage, this is a copy rather than a recovery.
The wider point worth taking: this is what verification manifests are for, and most people never generate one. Anybody moving irreplaceable media should.
On the bench
The retained manifest was verified against the destination before any recovery assumption — professional offload software recording every transferred file with a checksum of its contents, which permits byte-for-byte confirmation rather than merely establishing presence. Missing entries were distinguished from failing entries, absence indicating incomplete transfer or subsequent deletion while checksum failure indicates the destination altering content, which are opposite problems requiring opposite responses.
The outcome
The manifest verified against the destination before any assumption, missing entries separated from failing ones, and drive health assessed independently. Free assessment, and no charge where the answer is a verification you can run yourself. The decode: the file you already have answers the question you asked. It records a checksum for every file at the moment it was read, so verifying tells you whether files are absent or present-but-altered — and those are entirely different problems.
Files missing after a media offload
Verify against the manifest before assuming anything, and stop writing to the destination. If your offload software generated a hash list, that file records a checksum for every item at the moment it was read, so recalculating and comparing tells you byte-for-byte whether content is intact rather than merely present. The result decides your response. Files listed and absent means an incomplete transfer or a later deletion, and the drive may be fine. Files present but failing their checksum means the destination is altering content, which is a much more serious finding. Check whether the original card has been reused, too.
Verify first — then call Oxford Data Recovery on 01865 593000; manifest checked against the destination before any assumption, missing entries distinguished from failing ones, drive health assessed independently.
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.