What does a file carved from unallocated space lack that a file recovered through its MFT record keeps?

## Two different recoveries When data has been deleted, there are two fundamentally different ways to get it back, and interviewers ask this because candidates routinely present the weaker one as if it were the stronger. **Record-based recovery.** The MFT record has been freed but not reused. It still describes the file: its name, the reference of its parent directory, its $STANDARD_INFORMATION and $FILE_NAME timestamps, its size, its security descriptor, and the cluster runs holding its data. Following those runs gives content *bound to* identity. You can say: this named file lived at this path, was this large, was created then and deleted then. **Carving.** The record is gone, or was never findable, so you search raw unallocated space for structure that the file format itself provides. Every common format opens with a recognisable magic value: JPEG with FF D8 FF, PDF with the ASCII %PDF-, GIF with GIF87a or GIF89a, and the entire ZIP family -- which includes modern Office documents, since a .docx or .xlsx is a ZIP container -- with 50 4B 03 04. Some formats give you an end marker (JPEG's FF D9, PDF's %%EOF) and others give you a length field in the header, and the carver reads forward accordingly. ## What carving cannot give you Everything that lived in the filesystem rather than in the file: - **No filename.** The name lived in the MFT record and the parent index, not in the bytes. - **No path.** You cannot place the object in a folder, which in an insider case is precisely the claim under dispute. - **No filesystem timestamps.** No created, modified, accessed or MFT-changed time. You may find timestamps *inside* the content -- EXIF capture time in a photograph, a document's internal creation metadata -- but those are author-controlled fields describing the document, not the filesystem's record of when the file sat on this volume. - **No owner or ACL.** Nothing ties it to an account. - **No deletion time.** Nothing says when it stopped being allocated. So the honest sentence about a carved object is: "these bytes were physically present in unallocated space on this volume". That is real, and it is much less than people assume. ## The failure modes of carving itself - **Fragmentation.** Simple carvers assume the file occupies contiguous clusters. If the file was fragmented, reading forward from the header runs into unrelated data, and the output is truncated, corrupt, or silently contaminated with someone else's bytes -- the most dangerous outcome, because the object still opens. - **Partial overwrite.** If some clusters were reallocated and rewritten, the carve yields a mixture. A JPEG that renders its top third and then turns to noise is the classic picture of this. - **False positives.** Any run of bytes beginning with a magic value looks like a file. Thumbnails embedded in larger documents, format headers inside archives, and coincidental byte sequences all produce spurious hits, so a carve of a large volume returns thousands of candidates that must be triaged. - **No end marker.** Formats without a footer or a length field are carved to a fixed maximum size, producing objects padded with unrelated trailing data. ## Using both honestly in a report A carved object still has value: hash it and compare against a known copy, and you have shown that *this specific content* was on the volume. Match its internal metadata against a document you already hold and the link tightens. But if the question you were asked is "did the design folder contain the drawings", a carved drawing with no path does not answer it -- it answers a related, weaker question. Say which question you answered. When you present carved output, describe how it was produced. "Recovered from the folder" is a claim about location that carving cannot support; "recovered from unallocated space on the same volume, not attributable to a directory" is what actually happened, and the difference is exactly the kind of overreach a competent challenge will find.