Data Recovery Case File · Portable Drives · The Window Is Real
Announcing Itself Is Easy and Reading the Filesystem Is Not
His enquiry separates two behaviours that most people report as one. A drive that "always shows up in the device console, but only intermittently appears in the file browser. When it does show, the full drive is visible, but it quickly stops working again before it's possible to retrieve" anything. Consistent at the device layer and intermittent at the volume layer — which places the fault at reading rather than at the electronics, and turns each mount into a resource.
| Media | Portable external hard drive — enumerating reliably on every connection; volume mounting intermittently and dropping shortly afterwards |
| Reported situation | Drive appearing in the host device console on every connection · volume appearing in the file browser only intermittently · full content visible when it mounts · access ceasing shortly afterwards · retrieval not achieved · contents required |
| Fault class | Read failure at the filesystem region with device electronics functioning — enumeration succeeding consistently; mount windows finite and to be spent on capture |
| Equipment used | Layer separation treated as localisation of the fault · no browsing permitted during mount windows · Atola Insight Forensic error-rate assessment across the structure region · imaged write-blocked with capture resumed across successive windows · losses mapped per file |
The decode: two layers, two demands, and where the difference points
What enumeration requires: the drive powers up, its controller initialises, and it answers a short exchange in which it states what it is and how large it is. That is a small amount of work and it does not involve reading the surface where files live.
What mounting requires: the system reads the filesystem structures from the medium and interprets them. That is a genuine read from the platters, of a specific region, and it either succeeds or does not.
So what his pattern establishes: the electronics work every single time and the reading works sometimes. The controller, the bridge board, the supply and the motor are all reliable — and the fault is in the surface holding the structures, or in the heads reading it.
Why that is a useful localisation: it eliminates the whole family of intermittent electrical faults that this symptom is usually attributed to. A failing bridge would produce inconsistent enumeration too, and his is consistent.
What the successful mounts prove: the structures are readable, sometimes. Seeing the full drive means the filing information was read completely — so it exists, it is intact, and the difficulty is in getting the drive to deliver it reliably rather than in whether it is there.
Why the window must not be spent looking: when it mounts, the instinct is to open folders and check what survived. That is the most expensive possible use of a limited opportunity — each mount may be one of a small number remaining, and browsing produces reassurance rather than a copy.
Why an ordinary copy also fails here: it starts at the beginning each time. A transfer interrupted by the drive dropping out has to be restarted, so the second window re-reads what the first already covered and nothing accumulates.
What works instead: imaging that begins the moment the drive presents, records its position, and resumes from where it stopped when the next window opens. Each mount extends the captured region, and the image is built across as many as it takes.
What must stop: repeated connection to check. Every cycle is a start-up and a read attempt, and the number remaining is unknown.
On the bench
Layer separation was treated as localisation of the fault — enumeration requiring only that the controller initialise and answer a short identifying exchange, while mounting requires a genuine read of filesystem structures from the surface, so consistent enumeration with intermittent mounting places the fault at reading rather than in the electronics. No browsing was permitted during mount windows, and imaging ran write-blocked with capture resumed across successive windows.
The outcome
The layer difference used to localise the fault, windows spent on capture rather than inspection, and the image accumulated across successive mounts. 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: appearing in the device console needs only a short identifying exchange, while mounting needs a real read from the surface. Yours does the first reliably and the second sometimes, which places the fault at reading.
Drive that appears reliably but mounts only sometimes
When it does mount, copy rather than look — that's the whole discipline here. Each mount may be one of a small number remaining, and browsing to see what survived spends an opportunity on reassurance. Better still, don't use an ordinary copy: it restarts from the beginning each time the drive drops out, so the second window re-reads what the first already covered and nothing accumulates. What's needed is imaging that records its position and resumes. Your two behaviours are informative, though: enumeration only needs a short identifying exchange, while mounting needs a real read from the surface.
Stop browsing it — call Oxford Data Recovery on 01865 593000; layer difference used to localise the fault, error rates measured across the structure region, capture resumed across successive windows.
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.