Is it true that once files are deleted from the recycling bin (or “trash” via Mac), they remain stored somewhere on a hard drive? If so, wouldn’t this still fill up space?
If you can fully delete them, are the files actually destroyed in a sense?
In: Technology
Everyone mentioning that computers, or drives don’t actually delete the file when you delete it is correct. In this sense, the chunks on the drive are marked unused so that they can be overwritten later.
However, I wanted to add a bit about why. It’s perfectly possible for a computer to delete a file by zeroing or writing random data to that part of the drive, but it’s done in the interest of speed.
***Fair warning, this is a bit more technical, and while I’ll try to make this easy to understand with no background, it might go slightly higher level than ELI5***
On a mechanical hard drive, this physical moving of the read/write head to write that data takes time. Just the same amount of time it would take to copy that file somewhere, since that’s basically the amount of data we’d be writing. From a mechanical hard drive standpoint, this potentially takes a long time, so they just mark the chunk of the disk as unused.
In terms of an SSD, we’re not waiting for a drive to physically move, or for the data to spin past a read head, since it’s all electronic. The issue is that on an SSD, the drive isn’t just discrete 1’s and 0’s. The flash memory that’s in an SSD carves the storage on it into logical blocks that consist of larger chunks of data.
Say for example, a block can hold 1000 bits of data. If you have a string 8 bits long, on a mechanical hard drive, you just have to zero those 8 bits. The problem is that an SSD can only read and write blocks of data. So for an SSD, even though there’s no physical wait time, it can’t just zero 8 bits. It has to find the block containing this data, read the entire block into memory, modify the 8 bits in question, and then rewrite the entire block. This, while still being faster than a hard drive in most cases, is painfully slow by SSD speed standards, since it has to work with much more data than the amount that’s being modified, and it has to both read and write that entire chunk.
## Bonus
If you’d like to get technical, this is why there’s a process on SSDs called TRIM. When your computer can support working with TRIM on SSDs, the SSD does the same thing a hard drive does, and marks this data unused. Now, because modifying an existing block is much slower than just writing to a block it knows is empty, what an SSD will do with TRIM (which happens in the background) is consolidate this data. Suppose you have 10 blocks of data. Each of them, like before, hold 1000 bits of data. Now suppose that 8 of these have data partially written to them. Say, 300 bits each. That’s 2400 bits of data, but spread over 8 blocks, so we only have 2 blocks that are empty (and as such, don’t need to be read and modified, so the SSD can just write directly to those without reading them first). If we have a file that’s 5000 bits, that won’t fit on the 2000 bits contained in those two empty blocks, so this would ordinarily be really slow because it would have to read, modify, and write at least 3 other blocks to store this new file.
If, however, we let TRIM operate in the background, it’ll go through when your drive is idle (if you’re browsing the internet, and not using a lot of the drive speed, for example), and consolidate that. So it’ll see that we have 2400 bits of data across 8 sectors of 1000 bits, and it’ll see that the rest is free space, so it’ll read those into memory, consolidate them, and write the data back. The end result is that we end up with 3 sectors, 2 are the full 1000 bits, and the third is the remaining 400. The other 5 sectors are zeroed and marked empty. This means that if we were to then add our 5000 bit file, instead of the performance hit and time it would take to read and modify a bunch of partial blocks on the SSD, it can just write that 5000 bits to 5 already empty sectors.
Latest Answers