Data Recovery Case File · Mac & Apple Systems · Not a Translation Problem

A Volume Unreadable on Its Own Platform Has a Structural Fault Rather Than a Compatibility One

This enquiry contains a test that has already been run and its result. A family member's external drive that became unreadable, where "the data is still taking up space but is unreadable" — held in the platform's own native volume format, and tested on a machine of that same platform, where they report "no luck." That last step eliminates the obvious explanation: a volume that will not open on the platform that wrote it is not failing to be understood, it is failing to be read.

The decode: what the native test proves, and what occupancy reporting adds

Why testing on the right platform is a genuine elimination: it removes translation. A drive unreadable on a foreign system may simply be in a format that system does not implement, and that explanation is now excluded.

What that leaves: damage. A machine that understands the format and still cannot open the volume is reading structures that do not make sense.

Why that is more serious and also more specific: the fault is in the volume. It is no longer a question of what software is available but of what the drive is returning.

Now the occupancy figure, which is the encouraging half: something is reporting it. A host that can state how much space is used has read enough of the volume to find its accounting structures.

Why that matters: it establishes partial readability. A drive returning nothing at all could not produce a figure, so parts of the volume are being read correctly.

What it also establishes about the content: it has not been erased. Occupied space means the accounting still describes content in place, rather than a volume that has been emptied.

Why the fault is most likely in the directory rather than the data: that is what fails first. Structures describing files are updated constantly and are the usual casualty, while file content is written once and left.

Why the platform's own repair tool should not be run: it writes. Verification and repair utilities rebuild structures by writing new ones, which is the wrong action while the originals are still the best source.

Why this format in particular rewards patience: it keeps redundancy. Modern volume formats maintain checksummed metadata and multiple copies of key structures, which frequently permits reconstruction where an older format would not.

What must happen now: the drive disconnected and left alone. Each mount attempt runs the same checks that are failing, and on a drive of unknown physical condition each attempt is also a start-up.

On the bench

Native-platform testing was accepted as excluding format incompatibility — a drive unreadable on a foreign system potentially being in an unimplemented format, an explanation removed once the originating platform also fails, leaving structural damage. Reported occupancy establishes partial readability, since a host stating space used has located the volume's accounting structures, and indicates content described as in place. Structures were interpreted offline with their duplicate copies.

The outcome

Native-platform testing accepted as an elimination, no repair tool permitted, and structures interpreted offline from a write-blocked image. 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: testing it on the right kind of machine was the useful step. It rules out a translation problem — and the space still showing as used means parts of the volume are being read perfectly well.

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.