Delete does not mean gone.

#What “delete” actually does

When you delete a file and empty the Recycle Bin (or run rm), the operating system does not overwrite the bytes that make up the file. It performs a much cheaper operation: it updates the filesystem's bookkeeping. The directory entry that pointed to the file is marked unused, and the disk regions the file occupied (its clusters or blocks) are marked as available for reuse. The content stays exactly where it was, now living in what forensics calls unallocated space, until the operating system happens to allocate those same regions to a new file and writes over them.

On NTFS the specifics drive recovery. Every file and folder has a record in the Master File Table ($MFT). Deleting a file clears an in-use flag in its $MFT record and returns its clusters to the free pool tracked by $Bitmap, but the record itself, along with the name, timestamps, size, and (for small files stored resident in the $MFT) even the full content, commonly survives until that record is reused. FAT marks the directory entry with a special first byte and unlinks the cluster chain; ext4 and APFS follow the same theme with their own structures. The vocabulary differs, the principle does not: delete is an instruction to forget where the data is, not to destroy it.

Most graphical deletions do not even go that far. The Recycle Bin is not a deletion at all. Windows moves the file into a hidden per-user $Recycle.Bin folder and records its original path and deletion time in a small companion file (the $I record) beside the untouched content (the $R file). Until the bin is emptied, the file is fully intact and trivially restorable.

#Recovering data from unallocated space and slack

Because the content persists, the first recovery technique is direct. If the $MFT record or directory entry still exists, tools such as The Sleuth Kit and Autopsy read that metadata and pull the file back intact, byte for byte, with its original name and timestamps attached.

When the metadata is gone but the content is not yet overwritten, examiners turn to file carving. Carving ignores the filesystem entirely and scans the raw bytes of unallocated space for the signatures that file formats begin and end with (a JPEG header, a PDF marked by %PDF and %%EOF, a ZIP local file header). Anything matching is reconstructed straight from the raw stream. Tools like PhotoRec, foremost, and scalpel do this at scale, which is why a “deleted” folder of photographs so often reappears in an examination.

There is a subtler reservoir called slack space. Storage is allocated in fixed-size clusters, and a file almost never fills its last cluster exactly. The leftover tail of that cluster is not zeroed; it can still hold fragments of whatever file previously occupied it. Slack routinely yields pieces of older, long-deleted documents that no user interface would ever surface.

#The filesystem keeps a diary

Recovering content is only half the picture. Modern filesystems are journaled: they keep running records of their own changes so they can recover from a crash. Those records are a gift to an investigator, because they describe what happened to files, including files that no longer exist. On NTFS the relevant structures are three:

• $LogFile: NTFS's transaction log. It records low-level metadata operations (record allocations, index updates) so an interrupted write can be rolled back or forward. Parsed carefully, it can reveal very recent creates, renames, and deletes.
• $UsnJrnl: the update sequence number change journal, a higher-level history of changes to files and directories. Each entry carries the file name, a timestamp, and a reason code such as FILE_CREATE, DATA_OVERWRITE, RENAME_OLD_NAME, or FILE_DELETE. Long after a file is gone, its name and the fact that it was created and later deleted can sit plainly in this journal.
• $MFT timestamps: every record carries multiple times across two attributes ($STANDARD_INFORMATION and $FILE_NAME), usually summarized as the MACB times (modified, accessed, changed, born). Comparing the two attributes is also how examiners spot timestamp tampering, since tools that forge times commonly update one attribute and not the other.

The change journal in particular turns “the file is gone” into “the file named quarterly-figures.xlsx was created at 09:14 and deleted at 17:52.” That is often all an investigation needs.

#Volume Shadow Copies and restore points

Windows quietly maintains point-in-time snapshots of volumes through the Volume Shadow Copy Service (VSS), the machinery behind System Restore and the “Previous Versions” feature. Snapshots are copy-on-write: when a block is about to change, its previous contents are preserved first. The practical consequence is large. A file that a user created, worked on, and deleted may still exist, whole, inside a shadow copy taken before the deletion.

Examiners mount the available shadow copies and treat each as a separate view of the disk at an earlier moment, then compare. A document scrubbed from the live filesystem is frequently recovered untouched from a snapshot the user did not know existed, complete with its own set of timestamps that help anchor a timeline.

#The system remembers the file

Even if every copy of the content were destroyed and every journal entry aged out, the operating system scatters records of a file's existence across dozens of unrelated places, most of them created for performance or convenience rather than forensics. A short tour:

• Prefetch: Windows writes a .pf file to speed up program launches. It records that an executable ran, how many times, and when it last ran: evidence a program executed even after the program itself is deleted.
• Registry keys: RecentDocs lists recently opened documents by type; OpenSavePidlMRU tracks files chosen in open and save dialogs; ShellBags record folders that were browsed, preserving the fact a folder existed and was viewed; UserAssist logs launches of GUI programs.
• Shortcuts and Jump Lists: LNK files in the Recent folder, and the per-application Jump Lists, store a target's full path, size, and timestamps, and often the volume serial number, so they attest that a specific file lived at a specific path even after the target is gone.
• Browser history and downloads: the SQLite databases behind Chrome, Edge, and Firefox record visited URLs, downloaded file names, and timestamps.
• Thumbnail caches: to render folders quickly, Windows stores thumbnails in thumbcache_*.db. A deleted photograph can leave its thumbnail behind, a small but recognizable copy of an image the user believed was gone.
• Event logs: the .evtx logs capture logons, external-device connections, and, where process auditing or Sysmon is enabled, process creation, tying activity to a user and a time.

Together these place a file at a path, at a time, in the hands of a user, with no fragment of its content in hand. The reservoir laid out in one place:

#Memory, pagefile, and hibernation

Not every trace lives in the filesystem. While a machine is running, the contents of open files, along with decryption keys and the plaintext of otherwise encrypted data, sit in RAM. Memory is volatile and vanishes at power off, which is why forensic practice captures it first when a system is found live. A memory image can contain a document that was never written to disk in cleartext.

Two on-disk structures preserve fragments of memory across reboots. The pagefile (pagefile.sys) holds memory pages the OS swapped out under pressure, and can contain slices of file contents or keys. The hibernation file (hiberfil.sys) is a compressed image of RAM written to disk when the machine hibernates; analyzed offline, it can surrender remnants of whatever was open at the time, well after the source files were deleted.

#The file was rarely in only one place

Everything so far concerns a single machine. In practice a file of any importance has already propagated, and deleting the local copy does nothing to the others:

• Backups: local snapshots (Time Machine, File History), image backups, and enterprise backup systems retain versions on their own schedules.
• Cloud sync: OneDrive, Google Drive, Dropbox, and similar services keep server-side version history and a recycle bin of their own, often retaining “deleted” files for weeks and preserving prior revisions.
• Email: a file sent or received as an attachment now exists in the mailbox of every recipient and on the mail server, independent of the sender's disk.
• Other endpoints and servers: file servers, collaboration platforms, and the laptops of anyone the file was shared with each hold their own copy, and those servers usually log the access.

For an investigator this reframes the problem. The question is not only “can we recover this from the suspect drive,” but “where else did this data come to rest,” and the answer is usually several places the person deleting never controlled.

#Where deletion genuinely reduces recovery

It would be inaccurate to claim data can never be erased. Three mechanisms genuinely defeat recovery of content, and an honest treatment has to say so plainly. What they rarely erase is the wider trail.

The first is SSD TRIM. On a solid-state drive with TRIM supported and enabled across the drive, filesystem, and OS, deleting a file causes the OS to tell the drive which blocks are no longer in use, and the drive's controller erases them during background garbage collection, typically within seconds to minutes. After that, classic carving of unallocated space returns nothing; many drives even guarantee zeros on any read of a trimmed address. This is real, and it is why SSD recovery is far less reliable than the spinning-disk intuition suggests.

Full-disk encryption (BitLocker, FileVault, LUKS) is the second mechanism. If a volume is encrypted and the key is unavailable, because the device is powered off and locked, then unallocated space is indistinguishable from random noise and carving is pointless. This also enables cryptographic erasure: destroy the key and every block of ciphertext becomes permanently unreadable at once, which is the design behind the instant secure erase of self-encrypting drives.

The third is deliberate overwriting. A tool that overwrites a file's clusters, and ideally all free space, with new data renders the original content unrecoverable on magnetic media. Modern guidance (NIST SP 800-88) is clear that a single overwrite pass suffices for current drives; the folklore of many-pass wiping is obsolete. The catch is completeness: overwriting one file commonly misses its copies in slack, journals, shadow copies, backups, and the artifacts already described. Wiping a single file is easy to do, and easy to do incompletely.

The honest summary is narrow. Content can be destroyed: by TRIM on an SSD, by encryption without the key, or by verified overwriting. But erasing all evidence of a file is a much higher bar than erasing the file, and it is one that ordinary deletion, and even most attempts at anti-forensics, do not clear.

#How an examiner actually approaches it

The reason any of this holds up is process. The evidence is preserved first, by imaging the storage through a write blocker and computing a cryptographic hash (SHA-256) of the image so any later change is detectable, and then all analysis runs against verified copies. Order matters too: because memory is volatile, it is captured before the machine is powered down, following the order of volatility set out in RFC 3227.

From there the method is correlation, not a single smoking gun. A recovered file, a change-journal entry, a shadow copy, a Jump List, and a prefetch record are independent sources; when they agree on a name, a path, and a time, the conclusion is difficult to dispute. The framework that ties collection, examination, analysis, and reporting together is set out in NIST SP 800-86, the standard reference for integrating forensic technique into incident response.