The answer is “it depends”.
When you move a file to the trash, it has not been deleted at all. It has simply been moved to a folder and it can later be moved elsewhere.
When you empty the trash, then it is actually deleted from the underlying file system. What this actually means, however, depends on your storage device and the operating system.
-
Most operating systems simply delete the file’s directory entry and mark the file’s blocks as free.
The free blocks will eventually be overwritten by data from new files, but that might not happen for a long time, depending on the operating system and its file system device drivers. Until the blocks are overwritten, software with knowledge about the file system can find them and access the data. This is how “undelete” utilities work.
-
If the device is an SSD, and it supports TRIM and the operating system is also supporting TRIM on the device, then after the file is deleted, the operating system will send TRIM commands to the SSD.
This will immediately mark the file’s blocks as “garbage”. Software trying to read those blocks through any normal means will get back all-zeros, but the data remains stored in the underlying flash chips until the SSD controller performs “garbage collection”, which might not happen for quite some time (see my earlier posts on the subject).
-
Some operating systems may provide a “secure delete” command. For example, older releases of macOS included an
srmcommand, which will overwrite the file’s data before deleting it. This is what the (no longer part of macOS) “secure erase trash” command did.This kind of secure erase works great for hard drives where there is (mostly) a direct correspondence between the logical blocks used by software and the physical blocks managed by the media.
It is less useful on SSDs because the SSD controller’s wear-leveling logic will cause the overwrite-data to be stored in different physical locations on the flash chips, leaving the original file’s content marked as garbage, and will remain stored in the chips until garbage collection takes place.
Keeping all this in mind, now it should be easier to understand @Simon’s comment about encrypting free space.
-
If you have files that were simply deleted (meaning the blocks have not been TRIMmed or overwritten), and the encryption process does not encrypt unused disk blocks, then software can read the free space and undelete the files.
-
If the files were overwritten or TRIMmed as a part of the deletion process, then it doesn’t matter if the encryption process encrypts free space, because the free space doesn’t have the deleted file data (although it may still remain in an SSD’s flash chips until garbage collection runs).
-
The encryption process might also explicitly wipe free space. It may do this quickly using TRIM or (if that’s not possible) more slowly by overwriting the blocks. This is functionally equivalent to wiping the space before encryption.
In all three cases, however, if you’re using an SSD, the deleted file data will remain in the flash chips until the garbage collection process erases those locations. Someone able to bypass the SSD controller (direct access to the flash chips or hacked SSD controller firmware) before garbage collection takes place could theoretically access the data.
This is why it is recommended that you enable encryption before you copy the first sensitive file to the device. This way there won’t be a plaintext version of the file anywhere in the flash memory, even in the garbage space.
As always, whether this is important for you depends greatly on how sensitive the data is. For myself and my data, I would probably just erase the device (either with TRIM or a one-pass overwrite) and then leave it connected-but-unmounted for a few days to make sure garbage collection has plenty of time to run. Will it be perfect? Maybe not. But I think it will be good enough for my data.