Data Recovery Case File · Apple Mac · The Name Collision
"It finds the missing partition, but when I enter the password it displays as incorrect": the two-twins trap decoded — the password was right; the structures it was offered were not
Two identical G-Drive ArmorATD 5TB portables on one desk: a trusted one, twelve months old and full, and a brand-new one being prepared. Both plugged into his MacBook while he was "formatting the new one to APFS Encrypted" — and, mid-task, he made the change he'd come to regret: "updating the name of the new hard drive the same as the old one" — the last human-visible difference between two physically indistinguishable drives, deliberately erased in the middle of a destructive operation. By the end of the session, the older drive no longer mounted. His triage was genuinely careful: Disk Utility showed "the data is still present" but unmountable; First Aid changed nothing; a recovery application recovered nothing useful; a second one found the missing partition — and then, the twist that brought him in: "when I enter the password for the hard drive, it displays as incorrect." He asked whether the files on the missing partition could be recovered. The decode below answers a better question first: why a correct password can be rejected — and what that rejection actually reveals.
| Media | Two identical 5TB G-Drive ArmorATD portables on one Mac — the year-old, full twin affected; a volume named after the owner himself |
| Reported attempts | APFS Encrypted format aimed at the new drive · mid-task rename creating two same-named twins · older drive unmountable thereafter · Disk Utility "data present" · First Aid no effect · two recovery applications tried; the second finds a "missing partition" but rejects the password |
| Fault class | Wrong-target/name-collision incident against an encrypted container — original key structures displaced, data region substantially intact |
| Equipment used | Write-blocked imaging of both twins · APFS container and keybag-structure analysis on the images · reconstruction of the original encrypted container · owner-supplied password applied to the correct structures · verified decrypt and extraction |
The decode: the collision, the wrong target, and why "incorrect" didn't mean incorrect
The trap, named: identical drives are distinguished by nothing but their labels, and he removed that distinction during a format — the one operation where aim is everything. The evidence pattern that followed — old twin unmountable, structures "present" but refusing to open, a discoverable partition that rejects the owner's password — is the classic signature of the encrypted format having touched the wrong twin: the operation intended for the empty newcomer beginning against the full veteran, replacing the front of its container with fresh encrypted structures before anything was finished.
Why the password bounced: an encrypted volume's password doesn't unlock the data directly — it unlocks key structures stored with the container, which in turn unlock everything else. The recovery applications were finding a partition and dutifully offering his password to the structures sitting at the front of the drive — the new, half-built container's structures, whose keys have nothing to do with his year of data behind them. "Incorrect" was those tools telling the truth about the wrong object. A rejected password in this genre signals wrong structures far more often than wrong memory — a distinction that matters enormously, because his actual container was not gone.
What he did right: he stopped. First Aid was the right instinct at the wrong tier — it repairs mountable-ish volumes, not replaced containers — and after two application-level attempts he brought the problem in rather than escalating to anything that writes. Encrypted formats double the stakes precisely because the keys live in a small, vulnerable home; every further tool pointed at that drive was a risk to the surviving copies of them.
The recovery: both twins imaged, the original container found where the format hadn't reached
Both drives were imaged write-blocked — the affected veteran and, for elimination and comparison, the innocent newcomer — and all analysis ran on the images. The interrupted format had replaced the container structures at the front of the veteran; but this filesystem keeps critical metadata at more than one location, and the analysis located the original container's surviving structures beyond the newcomer's half-written frontage. From those, the original encrypted container was reconstructed on the image — and his password, offered at last to the structures it was actually made for, was accepted first time. The volume unlocked and mounted read-only; a year's estate presented with names, folders and dates intact, and was extracted and verified.
The outcome
The "missing partition's" files — in truth, the original volume entire — delivered on new media, decrypted by his own password once it was finally asked of the right lock. The honest caveat he was given up front, recorded here for the genre: this ending depends on the original key structures surviving the interruption, which a free assessment on write-blocked images establishes definitively before any fee exists. His did. The two twins went home physically labelled — in pen.
Two identical drives, and a format or encryption job to do
Unplug the one that isn't the target — aim is the entire game, and one cable removed makes the wrong-target click impossible. Rename before risky operations, never during, and label identical drives on their shells rather than trusting on-screen names. If a drive stops mounting after such a session and recovery tools reject a password you know is right, stop offering it — each tool may be interrogating the wrong structures, and the ones that matter are best approached read-only, on an image, once.
The keys may well survive — call Edinburgh Data Recovery on 0131 202 0491; imaged first, structures reconstructed, one written figure, no recovery, no fee.
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.