Data Recovery Case File · Portable Drives · A Working Route Exists Now
One Host Coping Where Another Does Not Is an Opportunity to Use Immediately
His enquiry contains a fact worth acting on before anything else. A portable drive that "makes the file browser crash whenever I plug it into my PC", but which he has connected to his phone and "can view the files on there, so it is still just about functional." A device that one host reads and another cannot is not equally broken everywhere — and the host that works is a route to the content that exists right now.
| Media | 1TB portable hard drive holding approximately 600GB — destabilising a desktop host's file browser; contents listing successfully on a mobile device |
| Reported situation | Portable external drive connected to a desktop machine · host file browser crashing on connection · drive connected to a mobile device · contents viewable on that device · drive described as marginally functional · approximately 600GB of content held |
| Fault class | Marginal readability with host-dependent behaviour — differing filesystem handling and timeout tolerance between platforms; readable window finite |
| Equipment used | Host-dependent behaviour interpreted as differing timeout tolerance rather than differing drive condition · drive removed from repeated desktop connection · imaged write-blocked under strict per-sector timeouts with readable regions taken first · marginal regions revisited across later passes · content reconciled against the listing obtained on the working host |
The decode: why two hosts differ, and what to do about it today
Why the same drive behaves differently on two machines: they handle a slow or unresponsive device differently. A desktop file browser expects prompt answers and can lock up or crash when a device stops responding mid-request, taking the interface with it.
Why a phone frequently copes better: its handling is simpler and more cautious. It typically reads less aggressively, caches less, and abandons a request rather than waiting indefinitely — so a drive that answers slowly is tolerated rather than fatal.
What that tells us about the drive: it is marginal rather than failed. Regions are being read successfully enough to list contents, and the difficulty is in returning them reliably and promptly.
Why listing on the phone is not the same as having the files: a listing reads the structures describing contents, which is a small operation. Copying reads every region the content occupies, and 600GB is a very different demand from a directory.
Why that distinction should not stop him using the working route: if a phone can copy anything off, it is worth doing. Content secured on another device is content that no longer depends on this drive, and the most important files should be taken first.
What the practical advice is, and it is specific: copy the smallest, most important things first through whichever host works. A marginal drive gives a finite amount of reading, and spending it on what matters is the whole of the strategy.
Why the desktop connections must stop: each crash is a device that stopped responding under load, and each attempt spends the drive further. Repeating an operation that fails is the most expensive thing available.
Why a full copy on the phone is unlikely to complete: the same marginality that crashes the desktop will surface during a sustained transfer. The phone tolerates a slow response better and cannot make a difficult region readable.
What is done properly: the drive imaged under strict per-sector timeouts, so no region absorbs the available time, with healthy areas captured first at full speed and marginal ones revisited across later passes.
Why the listing he already has is useful to keep: it records what should be there. Names and sizes give a target to reconcile a recovery against, and a screenshot of it costs nothing.
On the bench
Host-dependent behaviour was interpreted as differing timeout tolerance rather than differing drive condition — desktop file browsers expecting prompt responses and destabilising when a device stops responding mid-request, whereas mobile handling reads less aggressively and abandons requests rather than waiting, so a slow-answering drive is tolerated. Listing reads structures only, while copying reads every region content occupies. Imaging ran write-blocked under strict per-sector timeouts with readable regions taken first.
The outcome
Host-dependent behaviour read as differing timeout tolerance, repeated desktop connection stopped, and readable regions captured first under capped timeouts. 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: your phone is not stronger, it is more patient. It abandons a slow request where a desktop browser waits and locks up — which means the drive is marginal rather than failed.
When one device reads a drive and another crashes
Use the working route today, and copy the smallest, most important things first — a marginal drive gives a finite amount of reading, and spending it on what matters is the whole strategy. The difference between hosts isn't the drive's condition: desktop file browsers expect prompt answers and destabilise when a device stops responding, while a phone reads less aggressively and abandons requests rather than waiting. Stop reconnecting to the machine that crashes, since each attempt spends the drive further. Keep the file listing you can see, even as a screenshot — it's a target to check any recovery against.
Use the working route now — call Manchester Data Recovery on 0161 871 0788; host behaviour read as differing timeout tolerance, imaged under capped timeouts with readable regions 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.