Call us — 0191 406 1051
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →

Data Recovery Case File · Second Fixes & Trade Handoffs · Verify Before You Leave

The Copy Inherited the Fault

His account is careful and it describes a job declared finished that never was. An older desktop where "when I tried to open or close anything, nothing happened. I took it to a local PC repair who recommended I transfer my data onto an external hard drive. When the job was completed I went to retrieve the enclosure. I opened it up and could not find any relevant files, so I returned to the shop. When he tried to start up the external drive it would work — it was running but nothing was opening." The same symptom, on both devices. That is not a coincidence and it is not a second failure — it is the first fault, carried across in the copy.

MediaOlder desktop internal drive and an external drive holding a transfer made from it — files inaccessible on both; original machine's condition to be established
Reported situationDesktop machine unresponsive when opening files · repair shop transferring data to an external drive · transfer declared complete · expected files not found on the external drive · external drive powering and running with nothing opening · same symptom present on both devices
Fault classTransfer made from failing source without verification — unreadable content copied as apparently complete files; source drive condition decisive
Equipment usedOriginal source drive located and secured as the priority · both drives imaged write-blocked · copied files tested against source content · source recovered under per-sector timeouts where reads had failed · every file validated by opening

The decode: what happened during that transfer, and what matters now

What his original symptom meant: a machine where clicking something produces nothing at all is usually waiting — blocked on a storage device that has stopped answering. The programs are not frozen in the ordinary sense; they have asked the drive for data and the drive has not replied, so everything stops until the request times out. That is a failing-drive symptom, and it was present before anything was copied.

Why the copy behaves the same way: because an ordinary file copy asks the source for each file and writes out what comes back. Where the source returns errors, the behaviour depends on the tool — some skip the file, some stop, and some write out what they managed to read and pad the rest, producing a file of exactly the right size that contains unreadable filler partway through. So the external drive can hold a complete-looking set of files, correct names, correct sizes, none of which open. The transfer copied the fault along with the data.

Why the job was declared complete: because copying finished. That is the gap worth naming: a transfer is not verified when the progress bar ends. It is verified when somebody opens files from the destination — a document, a photograph, something from several different folders. Nobody did that, on either side of the counter, and it is the single check that would have caught this the same day.

The thing that matters more than anything else now: where is the original drive? Everything depends on it. If the old machine is intact and the drive still in it, that is the source and the real asset, and it should be secured immediately and not powered further. If it has been wiped, reused, or the machine disposed of, the position is far worse — because then the padded copy is all that remains. He should establish this today, before anything else happens to that machine.

Why the shop is not the villain: the recommendation to get data off a failing machine was correct, and doing it was the right instinct. What was missing was verification and, more fundamentally, the recognition that copying from a failing drive is not a file-transfer job — it needs imaging with timeout control rather than a copy that asks once and moves on. Those are different trades and it is reasonable that a general repair shop does not have the second.

What the copy is still good for: not nothing. The file names, folder structure and sizes on the external drive establish exactly what existed and what should come back, which makes the recovery targeted.

On the bench

The original source drive was located and secured as the priority, since everything depends on whether it survives and a machine left in service writes continuously. Both drives were imaged write-blocked, and the copied files tested against source content — establishing which had transferred intact and which had been padded to size around unreadable regions, since the two are indistinguishable from a file listing. The source was recovered under per-sector timeouts where reads had failed, and every file validated by opening rather than counted.

The outcome

The source drive secured first, both drives imaged and the padded copies identified against real content. 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, for anyone whose transferred copy will not open: the copy inherited the fault rather than developing one. An ordinary file copy asks the source once and writes back what it gets, and where reads fail some tools pad the remainder — producing files of exactly the right size and name that contain filler. A transfer is not finished when the progress bar ends; it is finished when you open files from the destination. Find the original drive today.

Data copied off a failing machine that won't open

Find the original drive today and make sure nobody wipes or disposes of it — that's the urgent part, because it's the only source of the real data. What's happened is that the copy inherited the fault. An ordinary file copy asks the source for each file and writes back whatever it gets, and where the source can't read a region, some tools pad the rest to the correct size — so you end up with files that have the right names and sizes and contain filler partway through. Nothing on the destination reveals that; it looks like a complete transfer. Which is why a copy isn't verified when the progress bar finishes, but when somebody opens files from the destination, out of several different folders. Copying from a failing drive isn't really a transfer job — it needs each sector given a time budget and retried on later passes.

Transfer completed but the files won't open?
Secure the original drive first — call Newcastle Data Recovery on 0191 406 1051; both drives imaged write-blocked, padded copies identified against source content, every file checked by opening.
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.