Shodan816

I believe my issue might just be related to this one. I use PocoMail as an e-mail client and when I tic "Temporary files' and run "Analyze," nothing shows up as being about to be deleted. However, when I "Run Cleaner," my client e-mail gets trashed somehow, disallowing the receiving of e-mails. This holds true whether I tic "Only delete files older than 24 hours," or not. This email client is portable and does not write to the registry or to any other folders that I am aware of. No files within the PocoMail folder appear to be changed or deleted, so it's something else relating to CCleaner's "Temporary files." I would like to know what temporary files are deleted or folders cleaned by CCleaner that do NOT show up when I "Analyze." Clearly it's somehting... PS) I've gone back as far as the last V3.X of CCleaner - same issue. Well, I finally solved the problem. It wasn't CCleaner after all - it was avast! antivirus! When avast! is set to scan incoming mail, it creates an empty folder "_avast_" as a subfolder under the "Temp" folder; When I run CCleaner with "Temporary files" ticked, it removes this empty avast! folder and pop3 email will no longer be imported (avast! stops it.) As soon as I create a new "_avast!_" folder under "temp," my incoming email works fine again. So leaving that folder in tact when running CCleaner fixes the problem. However, keep in mind that if you do have this same scenario, you must do one of two things; disable the cleaning of temporary files in CCleaner and then add the files in that folder that you do want cleaned via the Winapp2.ini file OR disable the scanning of incoming pop3 mail in avast! (my personal choice.) If there is a way to make exceptions to ticking "Temporary files," I am not aware of it. Now that avast! is doing this, it might be a nice improvement to be able to exclude files and/or folders of your choice while cleaning temp folders. Suggestion for Piriform. And oh, by the way, it's certainly possible that you could be running other apps that create temporary files or folers in your temp folder and CCleaner may be having an adverse effect on them, as well.

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....

For those of you who tried the 'SendTo' experiment and viewed the deleted folder in Windows Explorer's Recycle Bin, indeed it 'appears' to delete while running CCleaner. I use XYplorer as a file manager, as it is far superior to Windows Explorer. Windows Explorer is playing tricks on your eyes. For those who still doubt that CCleaner will not delete this copy of either the SendTo folder or all or part of the Start Menu, I would have those of you with the technical expertise to drop to a DOS prompt and navigate to your $Recycle.Bin and further to the RB's subfolder (S-blah-blah). There, I assure you, you will see the folder that Windows Explorer made you believe was deleted by CCleaner (or by right click and Delete in the Recycle Bin, for that matter.) After successfully running the batch file below, the folder will truly be gone from the Recycle.Bin. Again, the files within these folders, are deleted by CCleaner. Only the skeleton of the folder is left behind. Certainly no big deal, but they will accumulate. If you want to delete these 'folder skeletons' that are left behind, here are the command lines for a batch file that will delete the folders in the $Recycle.Bin that CCleaner will not (at least not so far.) To run this from a command prompt, eliminate one of the two'%' signs in both places first: =========================== @echo off rem Be sure you change the S-* number to YOUR $Recycle.Bin designation number rem The following command also works when run from volumes other than C: for /d %%a in (c:\$recycle.bin\S-1-5-21-2289612737-1512734087-2000572463-1000\$*) do rmdir /s /q %%a =========================== CAUTION: If you accidentally delete ANY folder by mistake and then run this, you'd better have a good 'undeleter' or backup. :-) I assure you this works, assuming you get the recycle bin designation correct. You may also modify it to delete 'CC undeletable' folders on other drives' $Recycle.Bins by adding additional 'for' lines and changing only the drive designation. Works like a charm. One word of caution, however: This 'fix' merely deletes folders in the recycle bin that CCleaner seems to refuse to delete, it does not erase them. I'll work on that another day. Hopefully future releases of CCleaner will make this procedure unnecessary.

"This deviates from the topic so may be irrelevant." Not really. The fact remains that certain folders, such as SendTo, Start Menu Folders, just to name a few, will not be removed from the Recycle.Bin by CCleaner. Can't get much more basic than that. I simply threw in the 'links part' to illustrate that CCleaner will delete these folder's contents, but not the folders themselves. Did you try creating a 'test folder,' dragging it to your Start Menu, deleting it and then running CCleaner?? Now check Windows Explorer and you will see the folder still there in the Recycle.Bin. That is my entire point.

Nergal wrote: "I'm sorry this sounds less and less like a true bug every post. why would one go through all these steps if they truly did want to delete their system folder, and if they didn't actually want to, I should think they'd be quite pleased that ccleaner "failed" to clean it" (sound of head shaking) Of course I was using 'SendTo' as an example ONLY. And I NEVER DID delete it. That was the whole purpose of copying it to a temp folder before deleting it! PLEASE try this simple TEST. Create a new FOLDER under your Start Menu. Put a few links in it just for good measure. Now delete it! It goes to the Recycle.Bin and CCleaner will delete the links but not the folder itself. And before someone asks 'Why would you delete a start menu folder?' I would ask you - Have you never deleted a Start Menu folder? And someone wrote 'If you want to empty the Recycle Bin simply right click on it and empty it.' Well, duhhhh.. Then I guess we don't need CCleaner at all, right? Sorry if I seem a bit frustrated at this point, but I do get this sinking feeling that no one is actually trying the simple test I am suggesting to prove that CCleaner indeed leaves 'certain' folders behind in the Recycle.Bin. It this is by design, then fine, but I can't believe it is. I just want someone to actually confirm that CCleaner really does leave some folders behind. I believe it's a bug until the author says it's by design.

OK, here is a very simple way to prove that CCleaner does not 'see' certain (protected) folders in the Recycle.Bin. Be sure your Recycle Bin is empty to begin with and copy your SendTo folder to a temp folder and delete it from there. The renamed SendTo folder should now be the only thing in your Recycle Bin. Now open CCleaner and UNtick every single category under both the Windows and Applicatoinos tabs EXCEPT 'Empty Recycle Bin.' Next, temporarily rename your winapp2.ini file (to anything, so that CCleaner.exe won't 'see' it) Now if you click 'Alalyze' you will see that the folder that now exists in your Recycle.Bin from the just now deleted SendTo folder is NOT listed. CCleaner does not 'see' it, and therefore will not delete it. I went all the way back to CCleaner V2.34 and it has NEVER seen these 'protected' folders.

RunAmok - I assure you this is not an attribute issue. At least not purely one. I removed the Read only and Hidden attributes on my SendTo folder before deleting it from my TEMP folder and the problem remains. As a crosscheck, I copied a different folder with all attributes set - Read only, Hidden and System - to my temp drive and deleted it. CCleaner erased it from my $Recycle.Bin with no problem whatsoever. Try it for yourself - copy that same SaveTo folder you are referring to, to a TEMP folder and make sure all attributes remain set. Now delete it to the Recycle Bin and I assure you that CCleaner will remove files within it, but will leave the folder itself intact in the Recycle Bin.

OK, this is interesting. I copy my SaveTo folder to a temporary folder and then delete it from there, as described above. Then I run CCleaner and it deletes the files within the SaveTo folder (now in the $Recycle.Bin) but not the folder itself. However, if I go to a command prompt and 'rmdir /s C:\$Recycle.Bin\S-1-5-21-2289612737-1512734087-2000572463-1000\\$R2UQ1UEOK' it deletes it! Seems more clear to me at this point that it's something within CCleaner that is not quite right if I can delete this stubborn folder from my command prompt but CCleaner can't...

Alan_B - I've tried it both ways. No difference. The folder remains in my $Recycle.Bin Andavari - Try for yourself. Go to your Users\(Name)\AppData\Roaming\Microsoft\Windows and copy the SendTo folder to a temp folder somewhere. This is just an example - other folders including the start menu exhibit the same behavior. Now go to that temp folder and you will see there are no System, Read Only or Hidden attributes set. Now simply delete this folder to the recycle bin, hopefully with your 'SendTo' shortcuts still in it. Now run CCleaner and you will see that the shortcuts that were in the folder are gone (either deleted or erased, depending on setting) but the folder itself (renamed $******) remains and the only way to get rid of it is with a right-click and delete in Windows Explorer. For what it's worth, if I ERASE this file with an erase utility (and not delete it to the recycle bin,) I have no problem whatsoever, so it almost seems to be the Recycle.Bin location that appears to be protecting it, and others... Hope this answers both questions.

RunAmok, I tend to agree with your 'Above all, do not harm' theory, but feel it is inherent in the OS and not in file or folder attributes. Another thing, if I go to User folder (name)\AppData\Roaming\Microsoft\Windows and copy both the 'Recent' and the 'SentTo' folders to a temp folder and then delete them, when I run CCleaner it purges (erases, per my settings) the Recent folder, including files therein from my Recycle Bin AND will remove files within the SendTo folder, but will not remove the SendTo folder itself. Perhaps there is no way around this for CCleaner to defy the OS ? I tried searching the registry for ' $R1D7AGJ' which is the name of 'SendTo' once it hits the recycle bin, but no hits. That seems to leave either attributes that I am not aware of or the OS itself. As a side note, I am 95% certain I saw this same behavior with CCleaner waaaay back on my Windows 98 machine years ago. Also, I have always run the portable version, if that tells you anything.

What you say is true of system files when they are in their protected system folders. However, I first copied these folders to a temporary (unprotected) folder and then deleted them from there. Once they are in the recycle bin, they should be fair game for deleting or erasing, even if CCleaner has to modify one or more file or folder attributes to do so. As further proof, after copying one of these 'protected' folders to my temp folder, I am easily able to erase it from Explorer, bypassing the Recycle Bin. Since I can delete and erase it from there, it should be deletable from the Recycle Bin by CCleaner, just as I am able to go to the subfolder under Recycle Bin and delete it permanently. I really do believe this is either a bug or an oversight in the utility.

I think I can explain why some folks have a problem removing folders from the recycle bin while others do not. If you simply delete 'normal' folders to the recycle bin, CCleaner deletes or erases them (depending on setting) just fine. However, now go to your User folder (name)\AppData\Roaming\Microsoft\Windows and COPY one of those folders, e.g. Start Menu, SendTo,etc. to a temporary folder. Now go to that temporary folder and delete that folder to the recycle bin. I believe you will find it will not delete from the recycle bin using CCleaner, probably due to some system attribute or similar issue. Hopefully this is a bug and not a system restriction that we have to live with. I've tried everything I know to get around it - unsuccessfully.

Experienced exact same problem - newer versions of CCleaner do not delete index.dat in the content.IE5 folder. I experimented and found the last version to delete this file (and probably other index.dat files as well) was CCleaner V3.0. So, to overcome this 'problem/bug' I now have 2 CCleaner folders on my PC. One for the latest version (CCleaner) and one (CCleanerStartup) strictly to run at boot time to delete index.dat files on startup. It'll do until this issue is dealt with...

Shows up just fine in Vista Business . . .

Probably one of the finest and unique features of CCleaner is the winapp2.ini, allowing the user to customize their file and registry cleaning beyond the 'standard.' Here is an idea to expand on this concept: How about a 'winapp3.ini' file that would be run only at system startup? I, for one, run CCleaner several times per day - just to 'clean house.' However, there are a few files that I would like to keep for daily use, but would like to securely delete at system startup each day - usually because these are the files that just keep growing and growing with system use. The idea would be to have CCleaner use the winapp2.ini file as it does now for normal cleaning (and startup) and a separate file, IF DESIRED AND IN ADDITION to winapp2.ini at boot time. This new file (winapp3.ini?), for advanced users, could contain only those file and registry entries that the user wants deleted at bootup. Thanks for listening...