Just today with CCleaner's Secure Delete (1-Pass) enabled it gave a crash dialog when it got to the Recycle Bin and didn't empty it. So I restarted CCleaner with Secure Delete (1-Pass) still enabled and it happened again for a second time. So I restarted CCleaner again, and on this third time I disabled Secure Delete and instead used Normal Delete and it didn't give any crash dialogs. I guess all this was a "soft crash", i.e.; didn't cause CCleaner to freeze/lockup.
It's also not very easy to repeat the crash because after Normal Delete emptied the Recycle Bin I can't get it to happen again, so I don't know if the original path lengths/names to the files in the Recycle Bin had had something to do with it or not.
I can save pictures via Firefox to my computer using very long file names in my 32 Bit Windows 7 PC.
But when I try to move them, Windows Explorer will declare that it cannot do so because the name is too long.
I can get around this by right-click sending the file to a winrar archive, then right-click extracting it to C:/P (Or where-ever I should wish to do so).
Windows Explorer seems to be the limiting factor in cases such as these.
Do you suppose your recycle bin error may have been caused by such as this, while attempting a secure delete?
Perhaps the secure delete process may not have been capable of handling very long names whilst regular cleaning can?
I tried to duplicate this under XP Pro x32 SP3 using various combinations of file names (up to 52 characters), sizes, paths, etc. I could not duplicate the failure as posted with secure delete enabled, although it did still fail to delete a folder in the recycle bin as described all through this thread.
As we've seen from other posts in this thread, there is definitely a problem cleaning the recycle bin in both XP and W7. The symptoms vary, possibly depending on differences between Windows releases or some other installation specific condition not yet nailed down, but in all cases CC appears to have cleaned the recycle bin (and a subsequent run and Analyze sees nothing to delete) but the recycle bin still contains something (in my case, any folder which was in there to start with).
Windows Explorer displays a combination of what it finds in the recycle bin and the contents of the INFO2 file which holds the details for each file/folder in the recycle bin, and CC correctly cleans the INFO2 file, resetting it to it's 'empty' state. But the actual folder is still there. Windows Explorer won't display anything at that point since there's no details in INFO2 to display, and the recycle bin 'Open' does the same, but a cmd window using the 'dir' command shows what's still there - and can be deleted with no problem using an rmdir command.
Do you suppose your recycle bin error may have been caused by such as this, while attempting a secure delete?
Like I already stated I don't know if I had anything to do with the path/file length that tripped up CCleaner, or if it was the sheer amount of files I sent to the Recycle Bin. It was the first time CCleaner has ever given me an error dialog, and I've been using it a little over eight years now, but at least it had in the Summary Results exactly where the problem was occuring.
OK, guys, I have found a solution to the particular problem I was having, but I still feel there is at least an 'oversight' by CCleaner, if not a 'bug.' As stated numerous times, there are certain folders that CCleaner will not remove from the Recycle Bin. Among them are SentTo and Media. I'm sure there are more. These folders will delete using Windows 'Empty Recycle Bin' but CCleaner will not delete the folders UNLESS they are specifically listed under Options/Include. Once I put the Recycle Bin folders there, e.g. C:\$Recycle.Bin\S-1-5-21-2289612737-1512734087-2000572463-1000\*.* then and only then will the folders be removed by CCleaner. Again, CCleaner will remove the contents of these folders, but not the folders themselves unless the Recycle Bin is listed under 'Include.' This resolves the problem I originally wrote about, but it seems to me that CCleaner should remove these folders without having to 'Include' them under Options....
Weird.... First of all, when I try to select the recycle bin, CC won't let me specify what I want. If I try to use the "folder" option to specify Sxxxxxx, it won't let me browse any farther than Recycler. The Sxxxxxx directory is never shown - even though I'm set to view hidden and system files/folders. If I try to specify a "file", it then lets me see Sxxxxx (and the folders in there), but wont allow any options as far as file types or wildcards. And it won't delete Recycler in the first case, or Sxxxxxx in the second case - which doesn't surprise me since both do have hidden or system attributes..
I also tried it with the folder option using the full path to %temp% and specifying *.* for the file name option, plus setting it to "all files, folders and subfolders". By the way, if I specified "*." (star-dot) for a file name, it came back with an error message box telling me that was not allowed "For system safety reasons". Anyway, a DOS window confirmed there were files and folders there to start with, and the Analyze showed the Temp Files line - with content - but... when I ran it, once again it deleted all files but not folders. A second Analyze didn't show the Temp Files line - which by then contained only folders.
Sooooooo... we know that this XP install - which works normally for everything else but is obviously somehow weird, is causing CC to screw up. I'm still digging to figure out what/why - and how CC "does it's thing"' which trips over whatever weirdness I have here. And again, for whatever reason, the portable version works as advertised here.
Shodan,
In your case, I'm still guessing that CC may be programmed to bypass what it thinks are 'reserved names', but will apparently do so if you've config'd a specific "Include". Still... that doesn't explain why it fails to delete those folders when they're in the recycle bin (where they should be fair game no matter what) and renamed to whatever special naming convention the recycle bin uses - although at that point it could determine what the original directory name was from looking in the INFO2 file.
Recently my v3.16 was bugged, among other issues it could not see any files in Recycle Bin, therefore could not remove them. I completely uninstalled CCleaner, searched my Win7 pc and removed all CC traces, reinstalled a fresh copy from filehippo. Now it works fine.
I've been down that road many times as I try to figure out where the problem is. The bottom line is that removing the current version (and any registry entries left behind by the uninstall) and installing version 3.10 works. Doing the same thing and installing any version after 3.10 does not. But for some reason, the portable versions always work fine.
First the good news.... I've fixed ALL the annoying and persistant problems I've had with CCleaner, starting almost a year ago - the failure to correctly empty the recycle bin if it contained a folder, and failure to delete folders elsewhere, both of which begin in release 3.11, and even the Recycle Bin icon not changing from full to empty problem which begin in release 3.19 (I think - I've lost track along the way).
All along I've strongly suspected it was something in the registry ever since I learned that the portable versions worked and the installed versions (both free and Pro) didn't. Multiple times along the way when I'd tried the old 'uninstall/reinstall' trick, (plus a registry scan to delete any left over CC keys) I'd found one 'leftover' registry entry which made me raise an eyebrow as I went through the registry and deleted any CCleaner entries after an uninstall. There was a key in HKCU\Software\Windows NT\CurrentVersion called "AppCompatFlags" which contained a sub-key called "Layers" populated with the full path to CCleaner's exe as a REGSZ set to "WIN95" - which stuck me as strange, but... every time I reinstalled, it was back, so I sorta ignored it as some strange thing that CCleaner's install did under XP for reasons known only to Piriform.
This time though, when I discovered that CC worked as it should when logged in as the system's Administrator ID (which I seldom use) and still failed when logged in under my own admin ID, comparing the registry HKCU entries between my ID and the Administrator ID, it reminded me about that key and the suspicious WIN95 value since it wasn't there in the Administrator's HKCU. To make a long story at least a little shorter, CCleaner installed versions, both Free and Pro, up to somewhere between 3.18-3.22 set that key - but only in the HKCU list for the id you're logged in with when installing. And that may even include releases before 3.10 although it only began causing the problems in 3.11. If you delete that "AppCompatFlags" key, CC works as advertised, correctly emptying the recycle bin and deleting folders where expected.
From at least 3.23 on (and maybe several releases earlier), that key is no longer set by a fresh install. And though I'd done half a dozen uninstall/reinstall (some with reg scans to remove 'left over' keys, some without) along the way), even when uninstalling 3.25, that key is not removed if it exists.
wait? so your computer at one point had been set to run ccleaner as win95, and because ccleaner (for past many versions) didn't support 95 it would fail (or was looking in win95 locations)?
devs,
Perhaps ccleaner should look in the registry for old appcompats in the registry (if it doesn't already) I know per se it wouldn't have fixed this instance but. . ?
Glad you got it fixed, though I wonder why it once was set to run as 95
Nergal, I don't have a clue why that key was there. This system was set up four or five years ago with XP, and it's stayed with XP (plus a service pack and a pot-load of patches) ever since. I don't remember exactly which release of CC I last did the 'full' uninstall (with registry cleanup), but not that long ago - somewhere around the 3.16-3.18 range, it was still regenerating that key when it installed. I'm sure the dev's could explain why that key was added on an XP system 'back when', but the bottom line is that the newer versions should check for the AppCompatFlags\Layer entry (which was the only one there) with the C:\program files\ccleaner\ccleaner.exe REGSZ WIN95 contents, and either delete that key, or the entire AppCompatFlags key if the CC contents is the only thing in the Layer entry - which mine was. The newer versions don't add that key, but they don't delete it on an uninstall - which would have fixed the problem several releases ago.