Data Recovery Case File · Solid State & Flash · Each Attempt Cost Something
The Disconnections Were Real and Nobody Caused Them
Her enquiry describes a sequence where the obvious response made things progressively worse. Checking files on a stick through an adapter, because her laptop has no full-size port: "my laptop popped up a message saying that I ejected the stick incorrectly, but I didn't even touch it. So I removed it and inserted it again, but the message appeared again, and after the second time, some of the files just randomly disappea"red. Files vanishing after repeated unexpected disconnections is not random — and the adapter she has to use is the first thing to look at.
| Media | USB flash drive accessed through a port adapter — host reporting improper ejection without user action; progressive file loss across reconnection attempts |
| Reported situation | Stick accessed through an adapter, the host lacking a full-size port · host reporting improper ejection without any user action · stick removed and reinserted · message recurring · files no longer present after the second occurrence |
| Fault class | Repeated unexpected disconnection with metadata updates interrupted — directory damage accumulating across events |
| Equipment used | Adapter eliminated and stick removed from use · imaged write-blocked on qualified equipment (DeepSpar USB Stabilizer 10Gb) · directory structures reconstructed on the image from surviving copies · signature carving alongside · files validated by opening |
The decode: what caused the disconnections, and what each one cost
What that message actually reports: the device stopped responding and the system removed it from the bus. The wording blames the user because the commonest cause is somebody pulling a stick out — but the system cannot tell the difference between a device unplugged and a device that simply stopped answering. She did not eject it; it disappeared.
Why the adapter is the leading suspect: she is connecting through one because her machine has no full-size port, so the adapter is in the path for every single access. Those adapters vary enormously — the common failings being unstable power delivery, poor mechanical contact in a socket that flexes when the cable moves, and bridge chips that drop the connection under load. Any of them produces exactly this: a device that works, then abruptly does not, then works again on reinsertion.
What each disconnection cost, and this is why the files went: when a stick is browsed, the system reads directory information and frequently updates it — access times, cached structures, and any metadata the file manager touches. If power is lost mid-update, the structures are left half-written. One such event may be survivable. Several, each interrupting a different structure while the previous damage is already present, accumulate — which is why files disappeared after the second occurrence rather than the first.
Why reinserting was the reasonable and wrong response: pulling it out and putting it back is what anybody does, and on a stick that is genuinely fine it resolves a one-off glitch. Here each cycle was another chance for an interrupted write. The moment worth acting on was the first message, and the right action then would have been to stop and use a different port or machine.
What is almost certainly true of the missing files: they are still there. Directory damage removes the entries describing files rather than the files themselves — which is why they vanish from the listing while the space they occupy remains used. Reconstruction from surviving structural copies usually returns them with names and folders.
What to do now: stop using the stick, and do not use that adapter for anything else until it has been tested with something disposable.
On the bench
The adapter was eliminated and the stick removed from use, the adapter being in the path for every access and unstable power, poor contact or a bridge dropping under load all producing exactly this pattern. The stick was imaged write-blocked on qualified equipment behind the DeepSpar USB Stabilizer 10Gb, which supplies controlled power rather than whatever an accessory provides. Directory structures were reconstructed on the image from their surviving copies, with signature carving alongside, and files validated by opening.
The outcome
The adapter eliminated, the stick imaged on controlled equipment and the directory structures rebuilt from their surviving copies. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone told they ejected something they did not touch: the system cannot distinguish a device unplugged from a device that stopped answering, so it blames you by default. Your adapter is in the path for every access and is the likeliest cause — and each reinsertion risked another interrupted write, which is why files went after the second time rather than the first.
Told you ejected a drive improperly when you didn't touch it
Stop reinserting it — that's the instinct, and here each cycle costs you. The message blames you because the commonest cause is someone pulling a stick out, but the system can't distinguish that from a device that simply stopped responding. If you're connecting through an adapter or hub, that's in the path for every access and is the likeliest culprit: unstable power, poor contact in a socket that flexes when the cable moves, or a bridge chip dropping under load. What each disconnection costs is real. Browsing a stick updates directory information as it goes, and losing power mid-update leaves those structures half-written — which is why files started disappearing after the second event rather than the first. They're very probably still there.
Stop reinserting it — call Guildford Data Recovery on 01483 901310; adapter eliminated, imaged write-blocked on controlled equipment, directory structures rebuilt from their surviving copies.
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.