How the Recycle Bin works
(last updated 05/27/2023)
First post of 2023!!! Woo!!!
You probably know about the Recycle Bin and even use it on a daily basis. But have you ever wondered: how does it even work? You might think “Oh, the files were simply moved to a system folder.” But if so, how does Windows know the file’s deletion date? How can there be multiple files with the same name in the Recycle Bin? Well, all those questions will be answered in this blog post.
Some information was taken from a video by YouTuber FlyTech Videos (check him out, he’s great!). Also, if FlyTech actually posts about this blog post (which is very unlikely as of posting this) then I will update the blog post with the link to the community post.
NOTE: The below information applies to Windows Vista and higher.
Where is the Recycle Bin?
You would assume that the Recycle Bin is located in the C: drive, and that’s reasonable. When you disable the “Hide protected system files” setting in Windows, you’ll see a $Recycle.Bin folder in the C: drive. You would probably immediately assume that’s where all the recycled files go. That’s actually only partially correct.
But thanks to the great power of testing on a real system with multiple drives, I found that Windows will add a $RECYCLE.BIN (yes, different casing is actually used) folder in every drive, in addition to the System Volume Information folder. But why? Well, let’s say you deleted a file in the D: drive. You’ll think it’ll get sent to the Recycle Bin located in the C: drive, but no, it’s actually sent to the D: drive’s Recycle Bin. This is done for several reasons, but I’m not that big of a tech nerd to cover that. Of course, to hide this, Windows merges items from every Recycle Bin into one listing, so it would seem like there was just one Recycle Bin.
Oh, and I haven’t even mentioned the fact that in each Recycle Bin folder, there are… multiple Recycle Bins that always lead to one single Recycle Bin. If you use the Command Prompt and dir /a in that directory you will see at least three folders, all starting with S-1-5-. These are known as security identifiers, or SIDs, and they are basically how Windows differentiates users and localgroups of different Windows installs. You can get yours by typing wmic useraccount where name="%username%" get sid into the Command Prompt. Obviously, this system was made so that multiple users on one Windows install won’t snoop around each others’ Recycle Bins.
Inside the Recyle Bin
Using console applications like the Command Prompt, it’s possible to enter a Recycle Bin and see what the Recycle Bin actually looks like. But, you would actually find files with strange names instead. For every deleted item Windows creates two files: a file with some metadata on it, and another with the actual file/folder data, normally used for restoring the deleted item. The metadata files always have their name start with $I, and the data files/folders always have their name start with $R. What comes after are a randomized 6-character string (each character can be 0-9 or A-Z), and the file extension (determined by what comes after the final . in the original file name, folders also have their “extension” determined; if no extension is found then it’s not added). What comes after $I (for metadata files) and $R (for data files) must match, or else the item won’t show up at all. Also, it doesn’t have to be 6 characters, must only include numbers and/or uppercase letters; it can be anything you want, as long as it matches!
The metadata files
FlyTech didn’t inspect the Recycle Bin on older versions of Windows, so I did. It turns out that the first 8 bytes of the metadata files determine the version number, and not actually a “header”. Each version has different formatting from one another, so let’s dive in!
Version 1
Used in: Windows NT 6.0 - 6.3 (Vista, 7, 8.x, Server 2008, Server 2012, etc.)
PS: Windows 10 and above doesn’t create v1 metadata files, but can still read them to retain compatibility.
| Hex location | Byte size (in hex) | Format/Endianness | Description |
|---|---|---|---|
| 0x0 | 0x8 | Little-endian | Version number (1 in this case). |
| 0x8 | 0x8 | Little-endian | File size (in bytes). |
| 0x10 | 0x8 | Little-endian | Deletion date (in file time format). |
| 0x18 | 0x208 | UTF-16 LE | Original file path. Spaces not taken up by the file path are filled with null bytes. |
Version 2
Used in: Windows NT 10.0 (10+)
| Hex location | Byte size (in hex) | Format/Endianness | Description |
|---|---|---|---|
| 0x0 | 0x8 | Little-endian | Version number (2 in this case). |
| 0x8 | 0x8 | Little-endian | File size (in bytes). |
| 0x10 | 0x8 | Little-endian | Deletion date (in file time format). |
| 0x18 | 0x4 | Little-endian | Length of original file path (including the null terminator). |
| 0x1C | 0x4+ | UTF-16 LE | Original file path (null-terminated). |