Summary
Drag a folder to the Recycle Bin, empty it, and the progress bar finishes in a second or two. On a mechanical drive holding forty gigabytes of holiday photos, that speed is the giveaway. Actually overwriting forty gigabytes would take many minutes. What the operating system did instead was much smaller: it edited a table. The bytes are still there. This is not a quirk of one filesystem. It is how nearly every general-purpose filesystem has worked since the 1970s, from FAT on early PCs to NTFS on Windows, ext4 on Linux, and APFS on macOS. Understanding why makes the recovery of “deleted” data feel less like magic and more like reading a library catalogue after someone tore out a card. What the filesystem actually does when a file is deleted A filesystem is really two things stacked together: an index that says where each file lives, and the raw blocks of storage that hold the file’s contents. On NTFS, the index is the Master File Table; on ext4, it is a set of inodes and directory entries; on the old FAT filesystem, it was the File Allocation Table that gave the format its name. Microsoft’s own documentation of the Master File Table describes how each file has a record listing its name, attributes, and the clusters where its data sits. When a file is deleted, the operating system does the cheap work. On FAT, the first character of the filename in the directory entry is replaced with a special marker (0xE5) and the clusters the file occupied are marked as available in the allocation table. On NTFS, the file’s record in the MFT is flagged as unused and its clusters are returned to the free space bitmap. The ext4 on-disk layout works on similar principles: the directory entry is unlinked and the inode is freed. None of these steps touch the file’s actual contents. The clusters, blocks, or extents that held the JPEG data still hold that JPEG data. The filesystem has simply forgotten they belong to anything, and is now willing to hand them to the next program that asks for storage. Until something else claims those blocks and writes over them, the photograph is intact. It has just lost its signpost. Why forensic tools can rebuild the file File recovery works on two ideas. The first is that the index and the data are separate, so even after the index entry is gone, the data pattern remains. The second is that files of a given type have recognisable shapes. A JPEG begins with the byte sequence FF D8 FF and ends with FF D9. A PNG starts with a fixed eight-byte signature. A PDF opens with %PDF- and closes with %%EOF. A tool scanning raw disk sectors can look for these signatures and reconstruct the file between them, even if every trace of the filename, folder, and timestamps is gone. The technique is called file carving, and open-source tools like PhotoRec have used it for years to pull holiday photos back off memory cards that had been “formatted”. Full-featured forensic suites go further. They read the surviving parts of the filesystem’s own metadata to recover filenames, folder structures, and modification dates, then cross-reference those against the carved data. The US National Institute of Standards and Technology runs an ongoing Computer Forensics Tool Testing program that publishes measured results for these tools against known test images, which is how the field distinguishes marketing claims from documented performance. How long a deleted file survives is not really a matter of weeks or months on the clock. It is a matter of how much the drive has been written to since. A drive that sat in a drawer will still hold the data. A drive used heavily for video editing will overwrite it in hours. The vague “weeks or months” figure quoted in consumer coverage is a rough estimate for a typical desktop with light day-to-day use. Why SSDs behave differently — and sometimes worse The picture above assumes a spinning hard drive, where the operating system controls exactly which physical sector a block lives in. Solid-state drives break that assumption, and the change matters for anyone thinking about privacy. An SSD has a controller that shuffles data across its flash cells to spread wear evenly, a process called wear levelling. The logical block address the operating system sees no longer corresponds directly to a fixed physical location. When a file is deleted, modern operating systems typically send a TRIM command telling the SSD which blocks are no longer in use, and the drive is then free to erase those flash pages in the background so future writes are fast. On a TRIM-enabled SSD, deleted data can vanish very quickly — often within seconds to minutes — and file-carving tools may find nothing. That sounds like a win for privacy, and for the everyday case it is. The complication is that wear levelling can also leave copies of old data stranded in flash pages that the operating system can no longer address at all. Independent researchers Michael Wei and colleagues at UC San Diego documented this in a widely cited 2011 paper, “Reliably Erasing Data from Flash-Based Solid State Drives”, which found that standard software-overwrite techniques failed to erase all copies of data on several consumer SSDs they examined. The consequence is awkward. On a hard drive, a careful overwrite reliably destroys the file. On an SSD, the drive itself decides where writes go, and only the manufacturer’s built-in secure-erase command — which tells the controller to reset every flash cell — offers a documented guarantee. NIST Special Publication 800-88, Revision 2, which superseded the 2014 edition in September 2025, distinguishes between “clear”, “purge”, and “destroy” for exactly this reason, and points to the drive’s own cryptographic erase or secure-erase functions for flash media. What “empty the recycle bin” was ever meant to do The Recycle Bin was designed as a safety net against fat-fingered deletes, not as a privacy tool. Microsoft’s original 1995 documentation treated it as an undo layer sitting on top of the filesystem’s normal delete operation. Emptying it does not add a shredding step. It just removes the safety net, letting the ordinary delete — the one that only edits the index — run to completion. This is why “empty the bin, then sell the laptop” has been catching people out for decades. The visible interface said the files were gone. The bytes on the platter said otherwise. Encryption changes the calculation. On a drive that was encrypted from the start with BitLocker, FileVault, or LUKS, the bytes on disk are ciphertext. Deleting a file still leaves those bytes behind, but without the key they read as noise. “Cryptographic erase” — throwing away the key rather than the data — is the reason a modern phone can be wiped in seconds. The data is not gone; the ability to read it is. What actually removes a file For a mechanical hard drive, a single full-disk overwrite with zeros is enough to defeat file-carving tools — guidance NIST’s SP 800-88 standard has held since the 2014 edition and reaffirmed in its September 2025 revision. The older folklore of thirty-five-pass overwrites came from a 1996 paper by Peter Gutmann aimed at drive technologies that have not been on sale for two decades. For an SSD, the drive’s built-in ATA Secure Erase or NVMe Format command, issued by a trusted tool, is the documented route. For an encrypted drive of any kind, discarding the key is faster and, if the encryption was in place from the beginning, equally effective. For a drive with anything sensitive on it that is leaving the house, physical destruction remains the only method that cannot be second-guessed by a controller firmware update. The strange part is how rarely any of this matches what the interface implies. A file goes into the bin. The bin is emptied. The progress bar finishes. Underneath, on the platter or in the flash, the holiday photos are still sitting there, waiting for something to need the room.