You delete a file in Windows, it gets dumped into the Recycle Bin, and later you fish it back out. What exactly happens during that whole process?

Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites.

The Question

SuperUser reader Jonath0n is curious about the Recycle Bin:

What does the Recycle Bin in Windows actually do? Is it just a glorified folder and a holding place for soon to be deleted files, or does it do something specific? Specifically, are files that are "moved" to the Recycle Bin actually moved on the hard disc, or are just the pointers to the files moved? I am a fairly experienced user, I just wanted a more depth explanation of the Recycle Bin.

So what's the story? How exactly does the Recycle Bin function as a sort of file purgatory?

The Answer

SuperUser contributor Tim Wijsman offers a peak behind the curtain:

The reference is removed, a metadata file is kept in the Recycle Bin to know the original location.

In the early days, on Windows 95 and 98 this was located in 

        \RECYCLED
    

. On Windows 2000 and later it was renamed to 

        \RECYCLER
    

. Since Windows Vista it is now a special folder called 

        \$Recycle.Bin
    

.

Use Process Monitor to see the I/O under the hood, put a filter on 

        Recycle.Bin
    

 and visit it. :)

For example, when I do this:

        notepad \$RECYCLE.BIN\S-1-5-21-0192837465-987654321-0123456789-1000\$EXAMPL5

    

Note: The long folder name is a User SID. The last folder name is a hash based on the metadata.

I get a file that contains metadata information like this:

                        Ö¸ÌC : \ P a t h \ T o \ S o m e \ E x a m p l e . t x t

    

The reason that the file path has spaces in between is because it is stored in wide byte chars, to support special characters for certain languages as well as unicode and what else. The earlier symbols are binary and contain information like the file size and permissions, as well as a pointer to the file data. In essence, it contains enough information to reconstruct the original reference...

It's sad that the Windows Internals book doesn't cover this, or else I would've had more reference. I haven't found any articles that go into detail on this, neither by Microsoft or by third party people. They probably do exist but I found it easier to go and reverse engineer the main concept...

Have something to add to the explanation? Sound off in the the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.