Metadata Recovery vs. Raw Recovery
Once a scan finishes, you often have two kinds of results in front of you: files that carry a name, path and other metadata, and files that carving found by content alone. A named result can still have the wrong content; an unnamed raw result can still be exactly right. Neither source of evidence is automatically more trustworthy than the other — what matters is assessing identity, mapping, content integrity and acquisition coverage separately, for each file, before deciding which version to keep.
- A named result can hold the wrong content; an unnamed carved result can be exactly right.
- Judge identity, mapping, content integrity and acquisition coverage separately for every important file.
- Old metadata can point to clusters that were later reused by other data.
- When results conflict, compare actual bytes and context instead of trusting the filename.
- Flag partial, conflicting or unverified output explicitly rather than presenting it as recovered.
What "metadata" and "raw" mean here
"Metadata-based" recovery reconstructs a file using the storage's own records — names, directory relationships, extent maps, timestamps. "Raw recovery" is a loosely-used label in recovery software; it is not one standardized algorithm, and different tools apply it to somewhat different things. This article uses it for content- or signature-based recovery, covered mechanically in File-System Recovery vs. File Carving, which this article does not repeat in depth. Worth disambiguating up front: a Windows "RAW" volume (a file system Windows cannot identify), a .raw disk image, and "raw device access" (reading a device's sectors directly) are three unrelated uses of the same word and should not be confused with each other or with "raw recovery" as used here.
A file result contains several independent claims
A single recovered file bundles several separate claims, each resting on its own kind of evidence: its filename and path, its size, its timestamp, the mapping of which bytes belong to it, whether that mapping is complete, and whether the content itself is valid. These claims can be true or false independently of each other. A named file can have the wrong bytes behind it because its extents were reused after deletion. An unnamed carved file can have exactly the right bytes with no name attached at all. Treating "recovered successfully" as one single yes/no judgment hides this; each claim needs its own check.
Metadata-based vs. raw results: what can be trusted?
Scroll horizontally to see the full table →
| Claim in the result | Evidence behind it | What it does NOT prove by itself | How to verify |
|---|---|---|---|
| Original name / path | Surviving records and parent-directory relationships | That the current extents still contain the original content | Cross-check against content validation |
| Logical file size | A file-system record, or a format's own length field | Completeness of the bytes actually acquired | Boundary, mapping and coverage checks |
| Correct extents / order | Metadata mapping, or format-based reconstruction | That those bytes were not later overwritten | Format parsing plus representative or full content check |
| Correct timestamp | A file-system record, or embedded format metadata | That it is the original creation time of the wanted version | Check the timestamp's origin and whether it's consistent with other context |
| Structurally valid file | Successful parse, internal checksums, successful decode | That it is the specific version the user actually wants | Identity/context checks, comparison to a known original if one exists |
| Matching hash | A match against a trusted reference hash | That the reference actually belongs to the wanted version | Confirm the reference's origin and that it covers the same byte scope |
| No missing reads | The acquisition map shows the relevant range as covered | Logical consistency of an actively-changing live system | Consistency and context checks, independent of coverage |
Why metadata can be correct while content is wrong
A deleted file's record can point to clusters that have since been reused by something else — the filename and path are accurate, the mapping they describe is not current. An old directory reference can point at a location that no longer holds what it once did. Partial mapping, or an unresolved lower storage layer underneath it (an unassembled RAID, an encrypted container), can leave a record technically correct but practically unusable. None of this is visible from the filename alone: a filename is not a check on content, and the fact that allocation metadata marks a cluster as "in use" is not proof that the file currently claiming it is the one that actually owns that content historically.
ext4: directory entry without a reliable extent map
A directory entry (name → inode number) survives, but the inode's extent-tree information does not.
Name and mapping are separate dependencies in ext4 — a surviving name does not guarantee a surviving mapping.
Do not assume undelete succeeded just because the directory entry exists; check specifically whether the inode's own content mapping survived.
Confirm extent data separately before trusting any recovered content attributed to that name.
APFS: an old object without current tree context
A scan finds an older object or record that is not reachable from the volume's current, actively-used object-map tree.
Objects are addressed through an object map and modified copy-on-write, so an old object does not automatically belong to a coherent, currently-valid checkpoint or snapshot.
Establish which object-map generation or snapshot the object actually belongs to before treating it as part of the current file history.
A single old metadata hit is not a promise of a complete recovered file history — validate the specific object's context before relying on it.
Why a raw result can be valid but lack original context
A carved result can pass every structural check a format offers — valid internal checksums, a clean parse, successful decode — and still have no connection to a filesystem path, directory, or original filename, because none of that context is part of the content itself. Embedded metadata (a document's internal title or date fields, for example) can help, but it is not file-system provenance — it is whatever the application that created the file happened to store internally, and it does not establish where the file actually lived or what it was called. A name assigned by the recovery tool is a generated label, not the original filename, and should be recorded as such. Conflict 2 below works through a full example of this situation.
Conflicting evidence: how to decide
When a named, possibly-truncated file and a complete carved candidate both exist, or a filename and detected file type disagree, or an older version and an embedded copy both turn up, or a file has a valid header but a damaged tail — do not automatically let one output silently replace the other. Keep both until each has actually been checked. Two full examples show how this plays out in practice.
Conflict 1: preserved name, reused content
A file-system record names a file report.docx with a plausible size, but the bytes in its referenced range are a different format entirely.
Name evidence and content identity conflict directly — this is not a successful recovery, even though the record itself is genuine.
Preserve the record's provenance, evaluate whether another view or candidate holds the actual content, and do not rename the mismatched file to make it look resolved.
Record the mismatch and the checks performed. Continue evaluating other plausible candidates where justified. If no matching content is found, report it as not recovered or unresolved within the examined evidence, rather than claiming that no matching version exists anywhere.
Conflict 2: valid unnamed content, incomplete context
A raw candidate passes complete ZIP integrity checks and contains a coherent, readable document, with no filesystem path attached.
Content is usable; original path and version identity are simply not established by this evidence.
Use any embedded title or date as a supporting clue only, and record the assigned filename explicitly as generated.
Treat this as a usable-but-unidentified result rather than silently promoting it to "recovered as <original filename>."
A third, shorter situation is also common: a named record and a raw candidate can turn out to share an identical SHA-256 hash while carrying different context. In that case, it's reasonable to store the one underlying byte stream once while still keeping both provenance records (the named reference and the raw discovery) — a matching hash confirms the bytes are the same, not that either provenance claim is more or less valid than the other.
Scroll horizontally to see the full table →
| Named, corrupt-content example | Unnamed, valid-content example | |
|---|---|---|
| Name / path | Supported by the surviving record; association with the recovered bytes is disputed | Unknown (no filesystem context) |
| Mapping | Supported (record points to extents) | Inferred (content-based boundaries only) |
| Content validity | Unverified / failed (bytes don't match expected format) | Validated (passes full format integrity checks) |
| Acquisition coverage | Unknown until the referenced range is checked against the acquisition map | Unknown until the carved range is checked against the acquisition map |
Evidence matrix comparing the two conflict examples above: neither column is uniformly "better" — each is strong on different claims, which is exactly why both need independent evaluation rather than a single trust ranking. If a recovered candidate cannot be mapped back to source ranges, its file-specific acquisition coverage remains unknown, even when other parts of the image have complete coverage.
Add acquisition coverage to the assessment
Read errors or not-attempted ranges in the source acquisition can overlap either a file's content or the metadata describing it, and this needs to be factored in alongside everything above. A placeholder zero in an unread region can look identical to an intentional sparse zero without a coverage map to tell them apart — see Disk Imaging vs. Cloning for that distinction in more detail. Without a map, do not assign a confident origin to a zero byte, and do not assume a result's dependency on unread ranges is zero just because a different part of the acquisition completed.
Record confidence and validate the selected version
A practical manifest for a disputed or important result records: a result ID; the original, inferred, or tool-generated name (labeled accordingly); the recovery method used; the source image's ID and the source volume's identity and start offset; the metadata record or offset, if available; the cluster size and content mapping, if available; the resulting logical size; a SHA-256 of the actually-recovered bytes; format-validation status; read coverage for the relevant range; and known limitations. Leave an unavailable field marked unknown rather than inventing a value, and only record an "original hash" field when a genuinely independent, verified reference hash exists for comparison.
Scroll horizontally to see the full table →
| Manifest field | Example value |
|---|---|
| Result ID | R-00142 |
| Name | report.docx (original, from MFT record) |
| Method | Metadata-based reconstruction |
| Source image ID | IMG-2026-0913-A |
| Source volume identity / start offset | Volume V2 on IMG-2026-0913-A, starting at sector 2048 — needed to map volume clusters to image byte ranges |
| Metadata record / offset | MFT record #48213, if actually available |
| Cluster size | 4,096 bytes |
| Content mapping | One allocated extent: volume clusters 190442–190498 inclusive (unknown if not available) |
| Logical size | 233,472 bytes (57 × 4,096) |
| SHA-256 (recovered bytes) | <hash of what was actually extracted> |
| Format validation | Passed / Failed / Not checked |
| Read coverage | Complete / Gaps in range X–Y / Unknown |
| Limitations | e.g. content not independently verified against a known original |
Numbers above are illustrative and mutually consistent for a plain, uncompressed, contiguous allocation. A sparse, compressed or multi-extent file needs a different content-mapping description, and real field values should never be invented to fill a gap.
Instead of a single numeric confidence score, use separate qualitative fields: identity established / partial / unknown; mapping supported / inferred / unknown; content validated / partial / unverified; acquisition coverage complete / gaps / unknown. This is this site's own documentation model for recording confidence, not an industry standard and not a probability of success. A valid-looking signature produces a candidate, not full validation on its own; a successful open, or a matching extension, is not sufficient either. A matching hash between two recovered results confirms they contain the same output bytes; a hash against a known original confirms exact recovery only when that reference genuinely belongs to the wanted byte stream and version — confirming that is a separate step, not something the hash match does by itself.
- Keep raw and metadata-based outputs separate initially.
- Compare sizes and detected type.
- Validate content.
- Check acquisition coverage.
- Determine identity/version.
- Deduplicate by actual bytes and context, not filename alone.
- Explicitly flag partial, conflicted or unverified output rather than presenting it as resolved.
This article covers why and when to question a result, and how to decide between conflicting outputs. The format-specific procedures for actually checking a given file type belong to How to Validate Recovered Data — the practical rule here is to keep trusted context and independently-validated content together, and to mark what remains unknown as unknown rather than implying it was checked.
Technical references: Microsoft: Master File Table — structured file records · Linux kernel: ext4 directory entries — name→inode dependency · Apple File System Reference — object maps, checkpoints, snapshots · PhotoRec documentation — content-derived candidates · GNU ddrescue — acquisition coverage mapping
Related: File-System Recovery vs. File Carving · How to Validate Recovered Data · What Overwrite Actually Destroys · Disk Imaging vs. Cloning for Data Recovery · NTFS MFT, Allocation and File Reconstruction · ext4 Superblocks, Inodes, Extents and Journal · APFS Containers, Object Maps and Snapshots.