On NTFS, what actually happens to a deleted file's data, and why can an examiner sometimes recover it?
answer
- a delete is bookkeeping, not erasing
- three structures change, the data does not
- MFT in-use flag, index entry, volume bitmap
- recoverability decays with reuse, not with time
- small files can live inside the record itself
basics
~20 sDeleting on NTFS only rewrites bookkeeping. The MFT record is flagged not-in-use, the directory index entry is removed, and the file's clusters are marked free in the volume bitmap. The bytes themselves stay on disk until something reuses those clusters.
solid answer
~50 sOn NTFS a delete is a metadata operation, not an erase. The file's Master File Table (MFT) record has its in-use flag cleared, the entry naming it in the parent directory index is removed, and the clusters it occupied are marked available in the volume bitmap. Nothing overwrites the data, so until the operating system allocates those clusters to another file the content is still physically present and an examiner can often recover it whole. Two consequences matter in an investigation. First, recoverability decays with use: a laptop that ran for three more weeks after an employee emptied a folder has had many chances to reuse those clusters. Second, small files can be *resident* inside the MFT record itself, so a freed MFT record may still carry both the name and the content until that record is reallocated.
go deeper
Be ready to say the three things a delete changes -- the MFT record's in-use flag, the parent directory index entry, and the volume bitmap -- and that the data itself is left where it is.
Explain why recoverability decays with disk reuse rather than elapsed time, and describe the resident-file case where content lives inside the MFT record itself.
Show you set expectations early in an investigation: image the machine before further use, and tell the requester which of name, size, timestamp and content you realistically expect to produce.
Own the policy angle: whether endpoints are configured so that this evidence exists at all, and whether an examination that can only prove existence is worth commissioning for the question being asked.
## What "delete" means on NTFS When a user deletes a file (past the Recycle Bin, or by emptying it), NTFS does not touch the file's contents. It performs three cheap metadata updates: 1. **The MFT record is marked free.** Every file on an NTFS volume has a record in the Master File Table describing it: its name, its timestamps, its security descriptor, and where its data lives. Deleting clears an in-use flag in that record's header. The record's fields are otherwise left as they were. 2. **The directory index entry is removed.** The parent folder's index no longer lists the name, which is why the file disappears from the user's view. 3. **The clusters are marked available.** NTFS tracks allocation in a volume bitmap; the bits covering the file's clusters are flipped to free. The data on those clusters is untouched. Erasing it would cost real I/O for no functional benefit, so no general-purpose filesystem does it on delete. ## Why recovery works, and when it stops working Because both the freed MFT record and the freed clusters are still readable, two different recoveries are possible: - **Record-based recovery.** If the MFT record has not yet been reused for a new file, it still points at the original cluster runs. This is the good case: you get the content *and* its name, its path (via the parent reference), its timestamps and its size, all bound together. - **Content-only recovery (carving).** If the record is gone but the clusters have not been overwritten, the bytes can still be pulled out of unallocated space by recognising file-format headers. You get content with no name and no metadata attached to it. Recoverability is a decaying function of *use*, not of time. A machine that was powered off an hour after the deletion preserves far more than one that ran for weeks: every new file, every temporary file, every browser cache write, every update is a chance for the allocator to hand those clusters to something else. Partial overwrite is the common outcome, which is why carved output is so often truncated or corrupt. ## Resident data: the small-file case NTFS stores a small file's content *inside* its MFT record rather than in separate clusters, if it fits (roughly a few hundred bytes, depending on the record size and the other attributes present). For such a file, a freed-but-not-yet-reused MFT record holds the filename, the timestamps and the entire content in one place. Short text notes, small configuration files and stub scripts are frequently recovered this way. ## What this is worth in an investigation In an insider case -- an employee who copied a design folder to personal storage and then emptied it -- this mechanism is why an examiner asks for the machine *quickly* and images it before further use. It also sets the honest expectation: recovery is opportunistic. You may get everything, you may get a filename with no content, and you may get nothing at all. On a modern SSD with TRIM enabled the content path can be closed within seconds of the delete, regardless of how little the machine was used afterwards. One direction-of-claim point to keep straight: the presence of recoverable data proves the file existed and was stored on this volume. It does not by itself prove who wrote it, when it was written, or that the person under investigation ever opened it. Those are separate claims needing separate artefacts. ## Common wrong answers - "Deleting overwrites the file." It does not; only a deliberate wipe or a full-volume encryption/erase does. - "The Recycle Bin is where deleted files live." The Recycle Bin is an ordinary folder with a rename; emptying it is the actual delete, and it is that step this question is about. - "Once it's deleted, it's gone." Frequently untrue on a spinning disk, and frequently true on a TRIM-enabled SSD -- the medium changes the answer.
- Does emptying the Recycle Bin change anything about this, or is it the same operation?Moving a file to the Recycle Bin is not a delete at all -- it is a rename and move into a per-user folder, with a companion metadata file recording the original path and size. The real NTFS delete, with the MFT record freed and the clusters released, happens when the bin is emptied. Until then the file is fully intact and trivially recoverable.
- If the machine was left running for three weeks after the deletion, what would you expect to still find?Expect metadata to outlive content. Freed MFT records and change-journal entries can survive because they live in structures that are reused at a different rate than data clusters, so a name, a size and a deletion time are plausible finds. The file contents themselves are likely partially or wholly overwritten. Plan the examination around proving existence, not around producing the file.
It is like removing a book's card from the library catalogue and marking its shelf space reusable. The book stays on the shelf, unfindable, until someone puts a different book there.
saying these in an interview costs you the question
- Says deleting overwrites or zeroes the file's data
- Thinks the Recycle Bin is the deletion, not the emptying
- Claims recovery depends only on elapsed time, not on disk reuse
- Assumes every deleted file is recoverable in full
- Treats recovered content as proof of who created it