Data Recovery Case File · Formatted & Logical Faults · The Number Is the Clue
An Absurd Size Demand Means the Software Read a Corrupted Length Field
His enquiry contains a number that looks like nonsense and is actually a diagnosis. A 2TB drive showing empty but containing files, its structure damaged by a command issued at a terminal, where recovery software "claims that 64,000 gigabytes is required — even on attempting to recover a single file." No file is that size and the software is not confused: it is faithfully reporting a length value that has been corrupted.
| Media | 2TB external drive with a host-native filesystem — structure damaged by a command issued from a different platform; content present, directory reporting implausible file lengths |
| Reported situation | External drive formatted for one platform · structure damaged during terminal use on another platform · drive presenting as empty while containing content · recovery software locating data · software reporting an implausible space requirement for recovery · requirement reported even for a single file · substantial work archive held |
| Fault class | Directory metadata corruption with content intact — file length fields returning invalid values; recovery requiring extents derived independently of the directory |
| Equipment used | Implausible size reporting interpreted as corrupted length fields rather than a software fault · drive imaged write-blocked at the block level before any further scanning · filesystem structures interpreted with their duplicate copies · file extents derived from allocation records and content signatures rather than directory lengths · recovered files validated by opening |
The decode: what the number means, and why the content is fine
What a directory entry records about size: a number of bytes, stored as a field alongside the file's name and location. Software preparing to recover a file reads that number to know how much space it needs.
Why a corrupted field produces exactly what he saw: the number is read and believed. A damaged length field can hold any value at all, including an enormous one, and the software dutifully reports that it needs that much room.
Why it happens for a single file as well as for all of them: each file has its own length field. If the region holding those fields was damaged, many of them are wrong — so picking one file does not avoid the problem.
Why this is a hopeful finding rather than a discouraging one: the number describes the metadata, not the content. The files themselves are where they always were, at their real sizes, and only the record describing them is damaged.
Why the drive showing empty fits the same cause: both symptoms come from the directory. A structure damaged enough to report impossible sizes is damaged enough to list nothing, and his own observation that it contains files confirms the content survived.
What the terminal command most likely did: wrote to the device rather than to a file on it. Commands that address a whole device write from its very beginning, over the structures describing the volume — which is a small region and an enormously consequential one.
Why that is a recoverable class of damage: it affects the start of the drive. A command interrupted or short in extent damages the description while leaving the overwhelming majority of the content untouched.
How the correct sizes are recovered: from the allocation records rather than the directory. Filesystems track which regions belong to which file separately from the length field, so a file's true extent is reconstructible even where its recorded size is nonsense.
Why signature-based recovery runs alongside: file types carry recognisable openings and, for many formats, internal structures giving their real length. A file located by signature reports its own size honestly, independently of anything the directory claims.
What must not happen: nothing further written to the drive, and no repair run from either platform. The structures that need reconstructing are the ones a repair would rewrite.
On the bench
Implausible size reporting was interpreted as corrupted length fields rather than a software fault — directory entries recording file length as a stored field which recovery software reads to determine space required, so a damaged field holding an arbitrary value produces an arbitrary demand, per file. Commands addressing a whole device write from its beginning over the structures describing the volume. Extents were derived from allocation records and content signatures rather than directory lengths.
The outcome
Implausible reporting interpreted as corrupted length fields, the drive imaged before further scanning, and extents derived from allocation records and signatures. 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: that number is the diagnosis. The software read a length field and believed it — so what is damaged is the record describing your files, at their real sizes, exactly where they always were.
When recovery software demands impossible amounts of space
Stop scanning and don't run a repair from either platform, since the structures that need reconstructing are the ones a repair rewrites. Read the absurd number as informative rather than as a malfunction: a directory entry stores each file's length as a field, and software reads that field to work out how much room it needs — so a corrupted field produces a corrupted demand, and it does so per file, which is why picking one doesn't help. Your content is untouched at its real size. True extents come from the allocation records instead.
Stop scanning it — call Manchester Data Recovery on 0161 871 0788; implausible sizes read as corrupted length fields, imaged at the block level, extents derived from allocation records and signatures.
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.