Just a quick post on the Windows Recycle Bin whilst it’s fresh in my mind (also because I posted some findings on Twitter, and will definitely lose them if I want to refer back another time). I figure since I did the testing I should get it down somewhere. Already spent the time to do it so may as well get it down on paper so I don’t have to redo it again another time 🙂

Recently, I was looking at a few different Recycle Bin parsers and thought it was time to con Eric into writing one for his toolkit.

It worked 🙂

I put together a few notes and test data for him, and from there he knocked it out in a few hours.

Of the tools that I tested, most performed well. One had a minor bug in it because Windows updated the format in Win10, but the author has since updated it, so all is well there.

The command line tools generally would parse individual files, rather than a whole directory. Eric’s has the option to do the whole directory rather than having to include a FOR loop. Some were specific to $I files or INFO2 files, but some did both.

If you’re after speed, rifiuti2 seems to be the fastest.

---

Testing Notes

During my testing I noticed something odd, that has probably been recorded elsewhere, but if it hasn’t here it is.

I noticed a lot of $I files in my Recycle Bin that didn’t correspond to active files that I could access through the UI.

I ran a quick test and exported the $I file in FTK Imager, and then restored the corresponding file to its original location. Looking at the recycle bin again I saw that the $I file still remained as an active file but the $R file was no longer there.

The only timestamps for the restored file that were updated to reflect the restore were the Entry Modified and INDX Entry Modified times.

I rebooted the machine to see what would happen and the $I file was still there.

I’m not sure why the $I file is not deleted immediately on the restore. I imagine it’s cleared out at a later stage.

If I deleted an individual file from the recycle bin, both the $I and $R file were marked as deleted in FTK Imager.

I cleared the Recycle Bin, and all the $R files were marked as deleted. I didn’t go through and check all the $I files though, but there were still allocated $I files. Clearing the recycle bin doesn’t appear to track down all $I files under the users Recycle Bin $MFT entry and mark them as deleted.

There could be other reasons why the $I file still remains in the Recycle Bin, so if anyone has any other ideas to test let me know. I’ve noticed this previously on Windows Vista, so it’s entirely possible that this has been the way that Windows has worked for a long time.

Summarised Findings

If a $I file and $R file exists, the file/folder is (most likely) in the Recycle Bin.

If the $I file exists, and the $R file doesn’t, then the file/folder has probably been restored. There doesn’t appear to be an indication in the $I file that the corresponding file has been restored.

If both are marked as deleted, then the file was deleted from the Recycle Bin.

But most importantly, you can con Eric into making a tool for you if you give him the spec and data.

 

---

Addendum:

Yogesh has done some additional testing that’s worth checking out.