Delete a photo from a traditional hard drive, empty the Recycle Bin, and the operating system can stop showing it without immediately overwriting the sectors that held the picture. To the user, the file has vanished; to the disk, much of its old data may still be sitting exactly where it was.
That difference is what makes deleted-file recovery possible. Until the old space is reused, software may be able to reconstruct a file from the filesystem metadata that survived the deletion or, when that metadata is gone, by searching the disk for recognizable pieces of the file itself.
There is an important modern exception. Solid-state drives can receive discard commands such as TRIM that tell the storage device those blocks are no longer needed, so the familiar “the bytes stay there until overwritten” rule is most dependable on traditional magnetic hard drives and other storage that has not discarded the freed blocks.
What the file system actually tracks
A file system is less like a shelf full of documents than a map telling the operating system where those documents live. The filename, timestamps, permissions, size and locations of a file’s contents are metadata layered over the raw storage underneath.
On Windows NTFS, much of that information lives in the Master File Table. Microsoft describes the MFT as containing at least one entry for every file and storing, either directly or by reference, the information needed to retrieve that file.
Linux’s ext4 uses a different layout. Its inode structures hold metadata and block maps, while directory entries connect names to inode numbers.
Apple’s APFS differs again, with features including snapshots, cloning and space sharing described in Apple’s APFS documentation. The implementation varies, but the underlying distinction is the same: the filesystem’s record of a file is not identical to every byte of the file’s stored content.
On NTFS, Microsoft says that when files are deleted, their MFT entries are marked free and may be reused. That changes whether the file is reachable through the normal filesystem without requiring the drive to overwrite every sector that previously belonged to it.
Why ordinary deletion works this way
For magnetic disks, immediately rewriting the full contents of every deleted file would turn a tiny metadata operation into potentially enormous amounts of extra disk activity. Deleting a multi-gigabyte video could require writing multi-gigabytes of replacement data before the computer could consider the operation finished.
Marking storage as available is much cheaper. The filesystem can remove or invalidate the information that makes the file normally accessible, then let some future file reuse the freed space when the computer actually needs it.
That is why an empty folder and an empty patch of physical media are not necessarily the same thing. The filesystem can consider a region free even while magnetic patterns representing the old data remain on the platter.
The distinction matters less to everyday use because the old bytes are no longer part of a live file. It matters enormously to recovery software and digital forensics, where unallocated space is itself something worth examining.
How recovery software finds a deleted file
The easiest recovery happens when useful filesystem metadata survives. A deleted NTFS record, for example, may retain enough information about the former file for a recovery tool to identify where its data was stored, provided neither the metadata nor the data clusters have since been reused.
This is a recognized forensic technique rather than a quirk of consumer recovery apps. NIST’s deleted-file recovery test material describes metadata-based recovery as using residual metadata left after deletion to attempt to reconstruct a file.
When usable metadata is missing, investigators can turn to file carving. NIST maintains a separate forensic file-carving testing program for tools that search raw storage independently of normal filesystem records.
A carver looks for recognizable structures associated with known file formats and tries to assemble the surrounding data into a usable object. Because it is working without the original directory entry, a recovered image may come back without its old filename, folder path or timestamps.
Carving also has limits. A file whose blocks have been partially overwritten may emerge damaged, while a heavily fragmented file can be much harder to reconstruct because its pieces were never stored in one uninterrupted run.
Where the old rule breaks: SSDs and discard commands
Flash storage adds another layer between a filesystem’s logical addresses and the physical cells holding data. SSD controllers manage flash internally, moving and erasing data in ways the operating system does not directly control.
Modern operating systems therefore use discard notifications to tell storage devices which logical blocks no longer contain useful data. Microsoft’s Windows documentation calls these file-delete notifications “trim or unmap” and says they are enabled by default for NTFS unless an administrator disables them.
NVMe has its own version of this mechanism. The NVM Express command-set specification defines deallocation through Dataset Management and related commands; the standard explicitly compares the operation with ATA TRIM and SCSI UNMAP.
Linux can also send discard requests, but when and how that happens depends on the filesystem and configuration. The fstrim documentation describes periodically discarding unused filesystem blocks on devices that support the operation.
Once a logical block has been discarded, ordinary recovery software can no longer assume that reading it will reveal the old file. Depending on the storage protocol and controller, a read may produce zeros, another defined value or an indication that the block is deallocated rather than returning the former user data.
That is why deleted-file recovery on an SSD is far less predictable than recovery from an old magnetic disk. Removable flash storage is variable too: USB bridges, flash drives and memory cards do not all expose discard behavior in the same way, so neither recoverability nor immediate erasure should be assumed solely from the device’s appearance.
Deleting a file and sanitizing a drive are different jobs
If the goal is simply to reclaim storage, ordinary deletion is enough. If the goal is to make sensitive information infeasible to recover before a device changes hands, that is a different operation: media sanitization.
The current NIST Special Publication 800-88 Revision 2 treats overwriting as one possible clearing technique for suitable rewritable media, but warns that SSD overprovisioning and wear levelling can make ordinary host-level overwriting inadequate for reaching every place old data may have existed.
For flash storage, that is why repeatedly writing over a single file is not equivalent to securely sanitizing the device. A controller may remap logical addresses behind the scenes, leaving the operating system without a direct way to target every physical location that has previously held the data.
Current sanitization guidance instead emphasizes using an appropriate, standards-based clear, purge, cryptographic erase or destruction method for the particular device and validating that the chosen process actually worked. Encryption can be especially useful when it has been implemented in a way that supports reliable cryptographic erasure.
Apple makes the same distinction visible to ordinary users: its Disk Utility documentation says secure-erase options are not available for SSDs and recommends enabling FileVault for additional protection.
The gap between interface and machinery appears elsewhere in computing too. A phone infers orientation from microscopic moving structures, while a checkbox CAPTCHA can evaluate signals beyond the checkbox itself.
On an old magnetic hard drive, deletion has the same hidden layer. The filename disappears, its space becomes available, and the platter may keep carrying the old magnetic pattern until some later write finally passes over those sectors and replaces what was there.