File-System Recovery vs. File Carving
Two routes lead from raw sectors to a recovered file. File-system recovery follows the storage's own records — directory entries, allocation structures, extent maps — back to the file they describe. File carving skips those records and recognizes file content directly, by its format. Which route applies depends on what actually survived, and the two differ most sharply once a file is fragmented, because only one of them has an authoritative map of where the pieces go.
- File-system recovery follows the volume's own records; carving recognizes file content by its format instead.
- Usable metadata may preserve names, folders, timestamps and extent maps; what survives varies by case.
- Metadata provides authoritative extent maps; specialized carving may infer fragments for some formats, without a general guarantee.
- Choose the route from what actually survived, not from the name of the event that caused the loss.
- Start with usable file-system views, then carve only the gaps they don't cover.
Two routes from sectors to files
The file-system route links directory entries and file records to the structures that describe the file's data. In ext4, a directory entry maps a name to an inode number, while the inode and its extent information describe the content mapping; other file systems organize these relationships differently. The carving route starts from content: recognizable headers, length fields, end markers or internal structure that identify a file's bytes without depending on surviving per-file allocation records. The difference is about which kind of evidence a method relies on, not about which brand of software implements it — many tools use both routes in the same scan.
What file-system recovery reconstructs
When enough of a file system's own structures survive, recovery can return names, directory relationships, sizes, timestamps, extent maps and resident content together, as a single coherent result. This can work even without a complete directory tree — individual file records can sometimes be found and reconstructed on their own. File-system recovery, as covered in this comparison, means reading and interpreting these structures; it does not require repairing the file system in a writable sense.
How carving finds file content
Carving searches sectors for the headers, length fields, end markers and internal structural patterns associated with a known format, then validates what it finds by parsing it as that format. It is not limited to a simple "look for a header, copy until a footer" search — some carving is genuinely format-aware and checks internal consistency, not just boundary markers. A broader sector scan can look for file-system records and content signatures in the same pass; these are two sources of evidence a tool can draw on together, not two separate products.
File-system recovery vs. carving: comparison
Scroll horizontally to see the full table →
| Dimension | File-system recovery | File carving |
|---|---|---|
| Source evidence | Directory entries, inodes/records, allocation and extent metadata | Recognizable content: headers, length fields, end markers, internal structure |
| Original filename / path | Can be recovered when the record survives | Not available from content alone; embedded metadata (EXIF, document properties) can suggest dates or titles but is not proof of the original path |
| Timestamps | File-system timestamps, when the record survives | Embedded/format timestamps only, where the format stores them — a different thing from file-system timestamps |
| Exact size / boundaries | From the record or extent map | Inferred from format structure (length fields, end markers), when the format provides them |
| Fragmented files | Extent map can usually identify and order the pieces | A simple contiguous carver struggles; specialized, format-aware carving sometimes recovers specific formats, with no universal guarantee |
| Supported formats | Usually independent of recognizing the file's own format, provided the tool supports the file system and the required stream semantics and enough metadata survives | Depends on format-specific signatures/parsing being implemented |
| Unknown formats | Can still recover content via metadata mapping, even without recognizing the format | Standard signature-based carving cannot reliably identify or delimit an unsupported format; custom rules or other content-analysis methods may sometimes help |
| Deleted / orphaned content | Recoverable if the record or sufficient metadata survives | Recoverable from content regardless of record state, if the data itself survives |
| Partial overwrite | Mapping may point at content that is already partially reused | Can produce a truncated or corrupted result without necessarily flagging it as such |
| Embedded files / duplicates | Distinguishes a document from its embedded images via structure | May return the whole document and its embedded objects as separate, overlapping hits |
| Encryption | Mapping may be intact, but content is still ciphertext | Cannot carve meaningful content from encrypted bytes without the decryption layer |
| Unreadable sectors | Can leave gaps in otherwise-identifiable content | Can break signature matching or structural validation at the gap |
| Validation | Record-level consistency plus content checks | Format-level parsing/checksum validation, since there is no record to cross-check against |
On compressed/sparse streams: don't conflate container-level compression (such as a ZIP's internal compression) with file-system-level compression or sparse allocation. An on-disk compressed or sparse stream may need file-system semantics to assemble and decode correctly, independent of whatever the file's own container format does internally. Recovering a file's main content stream also does not by itself confirm that alternate data streams, resource forks or extended attributes survived, or that the destination file system can even store them.
Fragmentation changes the problem
Metadata can describe a file stored across several non-contiguous extents, in any order, and a simple carver has no inherent way to know this. A specific, illustrative example makes the difference concrete: a four-block file whose content sits in volume blocks 100–101 and 900–901, with unrelated data occupying everything between them. A tool working from the extent map reads blocks 100, 101, 900, 901, in that order, and reconstructs the file correctly. A naive carver that assumes file content is contiguous instead reads 100, 101, 102, 103 — and the last two of those are unrelated data, silently appended as if they belonged to the file. Specialized, format-aware carving can sometimes recognize that block 102 does not continue the format correctly and search further for block 900 using internal evidence (a length field, an internal pointer) — but this depends entirely on the specific format providing that evidence, and is not a general guarantee for fragmented recovery.
File format determines what carving can infer
A contiguous JPEG with a simple header and no internal structure needing cross-references is relatively carving-friendly. A ZIP or DOCX, which stores an internal directory of its own compressed parts, gives a format-aware carver more to validate against, but also more ways to fail if that internal structure is damaged. An MP4 can have its actual media data intact while critical structural metadata (which maps time to byte position) is separate and essential — recovering readable bytes is not the same as recovering a file that plays back correctly. A plain text file, with no distinctive signature at all, is a difficult carving target almost by definition. Across all of these, a recognized header is a candidate, not proof of a complete file — embedded objects and duplicate signature hits inside a single container format are common, and should not be mistaken for the same content appearing twice.
Deletion, formatting and damaged metadata require different routes
What actually determines the right approach is the state of the structures and content on the volume, not the label of the event that caused the loss. A quick format does not necessarily destroy every old record; whether old data and metadata survive depends on what has been written to the volume since, and on how much deallocation (TRIM, on an SSD) has occurred. The same symptom — "I formatted the drive" — can leave outcomes ranging from substantial metadata-based recovery to partial carving results or no recoverable old content at all, depending on overwritten structures, subsequent writes and deallocation behavior.
Use both methods without losing context
A sensible scan starts by evaluating whatever file-system views are still usable, then uses carving specifically for gaps and orphaned content those views don't cover. When combining results, preserve the provenance of each recovered item (which route found it), deduplicate carefully rather than by filename or size alone, and validate content before trusting it. A larger total file count from adding carving results is not, by itself, evidence of a better recovery — some of that count can be duplicates, fragments, or false positives.
Deleted, fragmented NTFS file with intact mapping
A deleted file's MFT record still exists and references two non-contiguous extents.
The extent map is the strongest available evidence for this file; a contiguous carver would not know to look for the second extent.
Reconstruct the file via the surviving extent map, provided the referenced clusters have not been reused.
Check that the reconstructed content matches the expected format, size and structure, and assess any gaps in the acquisition map. Compare against a trusted original hash when available. Without such a reference, report the validation performed rather than claiming that no overwrite occurred.
Lost directory tree, surviving file records
The directory hierarchy cannot be walked, but individual file records can still be located.
Structural recovery is not an all-or-nothing proposition — partial metadata can still return content and some names without the full hierarchy.
Reconstruct what the surviving records support directly, rather than defaulting straight to carving.
Check which attributes (name, size, content) each recovered record actually supports before presenting results as complete.
Overwritten file-system records, contiguous photo content preserved
File-system metadata for a set of photos is gone, but contiguous JPEG content is still physically present.
Carving can return usable content here even though the file-system route has nothing left to work with.
Carve the volume, checking the full image rather than assuming a quick preview is representative of every result.
Open a representative sample of recovered images to confirm they are complete and not just valid headers.
ZIP/DOCX with embedded images
A scan returns what looks like several separate hits: a complete document and what appear to be its embedded images.
These can be one logical document and its internal parts, not independent files — raw hit count is not a recovery score.
Check the container's internal structure to see whether the "separate" hits are actually components of the larger file.
Open the assembled document and confirm its embedded content matches before reporting duplicate finds as distinct recoveries.
Scroll horizontally to see the full table →
| Evidence state | Preferred route |
|---|---|
| Valid, complete metadata | File-system route |
| Partial metadata | Reconstruct what the metadata supports, plus targeted carving for the gaps |
| No usable mapping, but recognizable content | Carving |
| Inaccessible ciphertext, or wrong RAID/pool mapping | Resolve the lower layer first — neither method helps until the data is actually readable |
| Content already overwritten or deallocated | Neither method recovers bytes that are genuinely gone |
Technical references: PhotoRec documentation (signature/structure-based carving, independent of file-system metadata) · Microsoft MFT developer notes (structured file records in NTFS) · ext4 extent-tree mapping · ext4 directory entries. The 100/101/900/901 block numbers above are illustrative, not measurements from a specific device or test.
Related: File Carving and Signature-Based Data Recovery · Metadata Recovery vs. Raw Recovery · Partition Recovery vs. File Recovery · NTFS MFT, Allocation and File Reconstruction · APFS Containers, Object Maps and Snapshots · ext4 Superblocks, Inodes, Extents and Journal · How to Validate Recovered Data.