Failed Delete & "$Recycle.Bin" Folder
Posted 17 July 2009 - 12:44 PM
I'm curious. Recently I uninstalled World of Warcraft. I waited about 45 minutes, and when it still hadn't completed, I ended the uninstall process. After that, I just deleted all the shortcuts and files that the program/installer/updates had left scattered all across my computer. Then my mystery began.
My recycle bin was empty, but I was still missing some disk space. Curious, I ran CCleaner, first in normal mode and then again with secure deletion (1 pass). Now, what intrigues me is that the normal deletion went quickly and smoothly, no error messages. Then when I ran the secure deletion pass, CCleaner hung for a while deleting WoW related big files (*.mpq's, the game data) that range from 500MB to 2.5GB each, but not from the Recycle Bin, but rather from hidden files in the C:/$Recycle.Bin/ directory.
Now, I had already run the normal process, so I'm curious as to why those files still exist, and I'm curious as to why the secure deletion pass was able to detect them whereas the normal one was not. Moreover, when I unchecked all the "hide protected system files from me" options in the 'folder options' section of the control panel (running windows vista business 32bit), I was able to see and navigate to that directory, but even deleting the files there didn't prevent CCleaner from attempting to delete them the next time it ran (I didn't wait for it to finish the first time that I ran the secure wipe).
Right now I'm running CCleaner in safe mode with secure deletion enabled, and I'm just going to wait for it to do its thing but I wonder... What gives?
1) What is $Recycle.Bin?
2) Why are there files that I can't see in $Recycle.Bin even though I have unchecked "don't show hidden folders" and "hide protected operating system files" that CCleaner can see and delete?
I realize that this may have something to do with the way in which I interrupted the original uninstall process, causing errors, but this post is purely related to my curious nature.
An additional tidbit of information that might be interesting is that when I deleted some other big files from my hard drive after this and emptied the recycle bin (50 files totaling 9GB), the recycle bin dialog that popped up was stuck at 0 bytes/sec and hung there for about 5 minutes before I got bored & restarted into safe mode to let CCleaner do its thing.
If anyone has any insights or questions as to the circumstances surrounding these events, let me know
Posted 23 July 2009 - 05:11 PM
You cannot delete the $Recycle.Bin Folder; it is built in and will always reappear when you delete it.
When the file is "deleted" by emptying the Recycle Bin, the space on the disk used by the file is designated as "free" without any changes being made to the file data itself. Future files will overwrite the data when they are saved on the disk. In other words, the data is not erased, but the address marking the data's existence is.
To see the files hidden in the $Recycle.Bin, you just do the process you described earlier, except that it's 'show hidden files and folders', rather than just 'folders'.
To your additional tidbit of information, your computer is just slow; mine does the same although not as frequently now. Usually, when you wait or restart the deletion process, Vista will finally total up the amount of files and the size being deleted and then starts the deletion process. This is what you see when it's actively deleting, but the number of files it says are deleting increases as it continues. It usually only happens when you are deleting a large amount of files. When I upgraded my RAM, I got less of this problem.
Posted 24 July 2009 - 02:45 AM
The structure of files in $Recycle.Bin is different in Vista from XP: they exist in pairs named $I.... and $R..... From memory I think that the $I is the info file (the file name. location, date deleted, etc) and $R is the data. Displaying the contents of the folder shows the 'real' file names, of course.
I don't know why CC would find one set of files in the recycler using normal deletion, and another using secure deletion. I don't know if there has been some interruption of the deletion process that may have left some corruption in the $I/$R pairing or CC's analysis stage. That's only a guess. The next time I do a CC normal delete I'll run a secure delete afterwards to see what happens.