Moin! :-)
Today I write this post about an already really well known artifact of Windows Systems - the Recycle Bin.
Why? Because I had a few more specific questions about the behavior of the recycle bin. I looked for answers to these questions but was not able to find any with a quick search - so I decided to just test it myself.
This post will first give a short overview of the storing mechanism of the recycle bin, something like the well known basics.
After this, I will look into my questions.
My questions were the following:
1. What does happen if the user restores a file?
2. What does happen if a user deletes the same file again after restoring?
3. What does happen if a file is deleted from PowerShell oder CMD?
4. Is there a difference between file systems?
I did the testing on a Windows 10 system. As far as I could see the behavior should by identical to Windows 11.
The basics
I will only give a short overview of the working without a deep look
As mentioned, I looked at Windows 10 or newer.
For this operating system the Recycle Bin stores two different files for deleted files:
1. The $R file - this file holds the data itself from the deleted file
2. The $I file - this file holds the corresponding meta data for the deleted file
The $I file holds data like the time and date of the deletion in UTC and the original file path and file name. Or, to describe it more correctly, the creation, last accessed and the last write timestamp of the $I file is the deletion timestamp of the original file.
If you have a file with the name "4n6.txt" and delete it, there will be two files in the Recycle Bin directory. One starting with $R, one with $I - and as suffix a 6 char long alphanumeric string. The extension is the same like the original file.
There is one Recycle Bin per partition in Windows. E.g. for drive C: it is c:\$Recycle.Bin
This means first there is an Recycle Bin on every partition.
Additionally, on NTFS file systems, the files in the recycle bin are stored under a folder that is named like the SID of the user who has deleted the file. I will show the difference to FAT32 later in this post. This post won't cover SIDs itself.
And - if the recycle bin is emptied or one specific file is deleted from the recycle bin both files, $I and $R are removed.
I used the tool RBCmd from Eric Zimmerman to do my research - you can find it at https://ericzimmerman.github.io/#!index.md
Okay, so let's start with the questions.
Restoring a file
What does happen if the user restores a file? I started with a complete empty Recycle Bin.
I deleted three files from my desktop and executed RBCmd with the following output:
We see in the output the three deleted files are referenced correctly.
Now I restore the files. And re-execute RBCmd with the following output:
It is the same - this is okay, because the tool parses the $I files. And these files are still there. But the $R files are gone.
I also restarted the system, but without any effect - the $I files are still there.
So, when restoring files, the $I files will stay. This means one can say that a file with a specific name, path and size was deleted in the past and than was restored.
Okay, second question.
Deletion of same file after restoring
What does happen if a user deletes the same file again after restoring?
I did a test on another drive with a clean Recycle Bin. First I deleted one file - restored it - deleted it again - RBCmd gives me the following:
As you can see, you have two $I files - different names - but same meta data - except for the deletion timestamp.
This means you can have more than one trace to the same file. For a file you only know the original timestamp, the file path, the file name and the file size. The content is only stored in the $R file.
Deletion from Terminal/CMD/Powershell
3. What does happen if a file is deleted via PowerShell or CMD?
When deletion is done from Terminal/Powershell/CMD there will not be any traces in the Recycle Bin. The behavior is similar to Linux - when not using the GUI the files will be deleted directly.
I also tested Double Commander as a different file manager and deleted a file from this app. For Double Commander the normal traces in the Recycle Bin still exist.
Different File Systems
So, what I did not mention yet - all testing was done with NTFS as the file system.
Is there a difference to FAT32?
I assumed that this is not the case because I thought the Recycle Bin is written by the Operation System and it is not important what the underlying file system is for the Recycle Bin - perhaps a bit naive.
So, assumptions need to get verified.
I created a FAT32 volume and created a few files and also deleted a few. There was one difference I could see:
On NTFS there was a folder per user in the Recycle Bin with the SID - and in this folder the files ($I and $R) are stored.
ON FAT32 the $I and $R files are directly stored in the Recycle Bin folder. You do not have any information on the user who has deleted the file in the Recycle Bin. Please find the ouptut of RBCmd of a FAT32 Recycle Bin below:
Conclusion
I had a few specific question and could answer them.
I want to say that you always should use different artifacts to validate results. E.g. you could use the USN journal for validating the deletion of a file. Never trust only one artifact. Look at the whole picture - this post only shows the answers to the really specific questions!
Also, important to say - this post only discusses the behavior of the Recycle Bin - it is not about deletion of files and if they are recoverable or not!
I hope that you also learned a bit and enjoyed your read.
