Inside the Windows Recycle Bin – What Really Happens When You Delete a File?

Note: This blog post is designed to complement the accompanying video embedded at the top of the page. The video provides an in-depth, visual demonstration of the concepts and code discussed here, making it an invaluable resource for learners.

We’ve all used the Recycle Bin. You delete a file, and it shows up there, waiting to be restored, or permanently removed. But what really happens under the hood when you press Delete?

In this article, I’ll take you through the technical details I covered in my video, following the same investigative process I used to uncover the Recycle Bin’s inner workings.

Delete vs. Permanent Delete

When you delete files via Explorer’s UI, they aren’t immediately erased, they’re moved into the Recycle Bin. Use Shift+Delete, and they bypass the Recycle Bin entirely. Similarly, deleting files from the command line or other apps removes them directly.

Tracking the Deletion

To observe the process, I used Sysinternals Process Monitor, filtering events to show only explorer.exe activity on the target file. This let me watch in real time as Explorer moved the file into a special hidden directory:

$Recycle.Bin\<User SID>\

$Recycle.Bin\<User SID>\

Here, I noticed two files created for every deleted file: one starting with $I, one with $R.

The $R and $I Files

• $R… – Contains the actual deleted file data.
  
• $I… – A small metadata file storing:
  
  • Version number
    
  • Original file size
    
  • Deletion timestamp (UTC)
    
  • Original path length
    
  • Original file path
    

The Recycle Bin’s Explorer view hides these technical details, showing only the original filename, location, deletion date, and size.

Hidden but Accessible

The $Recycle.Bin folder is hidden by default. Using command-line tools (dir /ah), you can reveal it and navigate into the subfolder matching your Security Identifier (SID). Each user and each drive has its own separate Recycle Bin.

Special Views in Explorer

Inside $Recycle.Bin, a desktop.ini file configures a special COM class that controls the custom Recycle Bin view. This is why you don’t see $I and $R file names when browsing through Explorer.

Confirming the Theory

I tested multiple files and confirmed the $I file always contained metadata in the same structure, while $R held the original file contents. Comparing the $R file to the original confirmed they were identical in binary form.

Per-Drive, Per-User

Each drive has its own $Recycle.Bin directory. Delete something from D:\, and it goes into D:\$Recycle.Bin\<User SID>\.

Final Thoughts

The Recycle Bin isn’t magic, it’s a structured system that stores both file content and metadata, wrapped in a custom Explorer view. Tools like Process Monitor make it possible to see exactly what’s happening.

If you want to master how Windows manages files, memory, and processes, check out my in-depth course: Windows Internals Master.

$1300

$1040 or $104 X 10 payments

Windows Internals Master

Broadens and deepens your understanding of the inner workings of Windows.

Become Windows Internal Master

TrainSec’s mission is to equip you with the deep technical skills to understand and secure the systems you work with. This is just one example of how a familiar feature hides interesting implementation details beneath the surface.

Before you go…

The TrainSec Knowledge Library hosts this article, dozens of free write-ups, and curated links to help you grow from curious developer to seasoned cybersecurity professional. New pieces constantly drop, subscribe to our mailing list and I’ll make sure fresh kernel tips (and occasional war stories) land directly in your inbox.