Data Recovery Case File · Desktop Externals & Aging Drives · Unplug, Don't Eject
Ejecting Is a Conversation, and It Had Stopped Answering
His enquiry describes a cascade that most people have lived through without understanding. A drive in a caddy: "I was trying to access a file and the drive became unresponsive. I tried to close the program, eject the hard dr"ive, and nothing would respond. An eject is not a switch — it is a request the device has to acknowledge, and a drive that has stopped answering cannot acknowledge anything, which is why the attempt to disconnect safely made everything worse.
| Media | 320GB hard drive in an external caddy — ceasing to respond during a file access; host unable to complete application closure or device ejection |
| Reported situation | Drive in an external caddy in normal use · file access attempted · drive ceasing to respond during that access · application unable to close · eject operation attempted and not completing · host unresponsive · contents required |
| Fault class | Read failure with the device no longer answering — outstanding operations preventing orderly disconnection; physical disconnection the only available resolution |
| Equipment used | Caddy eliminated on a native connection · Atola Insight Forensic error-rate assessment · imaged write-blocked under strict per-sector timeouts with retries capped · healthy expanse captured first · losses mapped per file |
The decode: why the eject could never have worked
What ejecting actually does: tells the device that no further operations are coming, waits for it to finish anything outstanding, instructs it to write out anything held in its cache, and waits for confirmation that this completed. Every step requires a reply. The point of the procedure is to guarantee that nothing is left half-done — which it achieves by not finishing until the device says it is safe.
So what happens when the device has stopped answering: the eject request joins the queue of things waiting for a reply that will not arrive. It cannot fail, because failing would require an answer too. It simply waits, indefinitely, and the interface offering it waits with it.
Why the program would not close either: for the same reason. An application with an outstanding read cannot exit until that read returns or the system gives up on its behalf — so it sits, unresponsive, holding a request that no longer has a recipient.
Why the whole machine slowed: each unanswered operation holds resources while it waits, and enough of them leave the system short. Nothing is broken about the computer; it is queued behind a device that has gone silent.
What to do instead, and it feels wrong: unplug it physically. The instruction everybody has absorbed is to eject before disconnecting, and it is correct for a working drive. For one that has stopped answering it is impossible — and a physical disconnection ends every outstanding request immediately, releases the system, and lets the machine recover.
Why the usual risk does not apply: ejecting protects against losing writes held in cache. But a drive that has stopped responding is not going to write those out regardless of how long anybody waits. The data at risk was already lost when it stopped answering, and waiting costs the drive further attempts at the region it cannot read.
So the rule, worth keeping: eject a drive that is working. Unplug a drive that has stopped. The distinction is whether it is still talking to you.
What the caddy contributes: a variable worth eliminating. It supplies power and interface, and a marginal one produces exactly this kind of stall.
On the bench
The caddy was eliminated on a native connection, an external enclosure supplying power and interface and a marginal one producing stalls of this kind. The Atola Insight Forensic assessed error rates, and imaging ran write-blocked under strict per-sector timeouts with retries capped — an unresponsive device holding outstanding operations indefinitely, which is why an eject cannot complete and why capture must impose its own limits rather than wait. The healthy expanse was captured first, with losses resolved to individual files.
The outcome
The caddy eliminated, error rates measured and the drive imaged under capped timeouts with the healthy expanse taken first. 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: an eject is a conversation, not a switch — it tells the device no more work is coming and waits for confirmation at every step. A drive that has stopped answering cannot confirm anything, so the request waits forever. Unplug a drive that has stopped; eject one that is working.
Drive that stops responding mid-use
Unplug it physically rather than trying to eject it — that feels wrong and it's the right move. Ejecting is a conversation: the system tells the device no more work is coming, waits for it to finish what's outstanding, instructs it to write out anything cached, and waits for confirmation at each step. A drive that has stopped answering can't confirm anything, so the request waits indefinitely and can't even fail. That's also why your program won't close and why the whole machine slows — each unanswered operation holds resources while it waits. The usual reason for ejecting is protecting cached writes, and a drive that isn't responding was never going to write those out anyway.
Unplug it — call Guildford Data Recovery on 01483 901310; caddy eliminated on a native connection, error rates measured, imaged under capped per-sector timeouts with the healthy expanse taken first.
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.