when I run CCleaner it purges (erases, per my settings)
Do you "Secure Erase" or "Normal Delete".
This can make a difference.
I ran a test using a handful of free cleaning tools and none of them including those that promise to delete files on reboot and also including CCleaner will delete a folder with the following attributes:
* Read-only
* System
Removing those attributes allows the folder to be deleted.
So possibly all of the cleaning tools I tried are smart enough to leave such folders alone as a safety precaution which would be wise if someone included something in the OS folder to clean, and/or Windows won't let them delete such folders - I don't know which that would be though.
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.
OK, after some testing, I can confirm that CC version 3.10 will delete a folder that's marked as read only (but see test results below) and any release from 3.11 on will not. I could buy that. Kinda. It does strke me as a shotgun approach to fix some specific problem where CC deleted some special folder which caused a problem though. CC doesn't seem to care about read only files, but it sure does care about read only folders. And I can't explain why the portable version doesn't care if a folder is set to read only and works as expected, but the normal install does care and won't delete them. Nor can I explain why, on this XP Pro x32 SP3 system ALL folders show as read only when I check the properties using Windows Explorer (and can't be reset) but the same folders do NOT show as read only when checked from a cmd/DOS window.
Viewing properties on a newly created test folder on the desktop (or any folder anywhere else for that matter) from Windows Explorer, the read only check box is totally green. I can click on it (it's then empty), click on Apply (it stays empty), but if I move to somewhere else and come back to check properties again, it's all green again. If, while I'm still looking at a folder's properties from Windows Explorer, I click on the read only box again when it's empty, I get a green check mark. And if I click Apply, I then see that it really is marked as read only when tested from a cmd/DOS window. But again, if I go somewhere else and come back to check properties from Windows Explorer, the read only box is all green again. And that's true even if I've reset the RO attribute from the cmd/DOS window.
For some reason, even though I can see that a folder does NOT have the read only attribute set (from a cmd/DOS test), there's something here that CC - and Windows Explorer - still sees and handles as if read only was set. Add one more entry in the Windows Wierdness list... Sometimes Windows makes my head hurt.... But at least I know now what changed in CC between 3.10 and 3.11, and why I started this chain with the symptoms I see on this system.
If, while I'm still looking at a folder's properties from Windows Explorer, I click on the read only box again when it's empty, I get a green check mark. And if I click Apply, I then see that it really is marked as read only when tested from a cmd/DOS window. But again, if I go somewhere else and come back to check properties from Windows Explorer, the read only box is all green again. And that's true even if I've reset the RO attribute from the cmd/DOS window.
My experience with XP was that DIR under CMD.EXE would tell the truth as it is,
whilst Windows Explorer would say what it could remember from the past.
DIR would show the contents of a folder with the "last accessed" date correctly shown for each file,
and it did NOT modify the "last Accessed" date whilst it did so.
W.E. would show the same information for the same folder, BUT although it gave no indication it had done so, it "accessed" each file on display.
DIR would show the change to Last Accessed on the files that W.E. had looked at, but W.E. persisted with how they used to be.
Alan_B, W.E. not reflecting changes would appear to explain some of the strange things I mentioned. But in this case where it seems to show the RO attribute set and DIR shows it's not - with no changes made for months - I think it's trying to tell me something (which CC evidently 'sees' as well) that I can't figure out - yet. DIR tells me that it's not really the RO attribute, and it's not an inherited NTFS permission since it allows me to change it without warning me that it's inherited and I can't change it at that level.
I've learned, for example, that W.E.will 'help' us by displaying what it thinks we want to see. For example, it displays the contents of the recycle bins on all hard drives as if they were one recycle bin - no matter which one you're looking at with W.E.. if you use W.E. to look at the subdirectories of RECYCLER on either of two hard drives C: and F:, it shows the interpreted contents of the RECYCLER folders from BOTH drives - but not the actual files and folder names as they exist in each RECYCLER. If I delete a file called test.jpg from some location in the file structure, what's actually in the username folder under RECYCLER is a file named DC4.jpg and detailed info about that file's original path and informaton/attributes contained in a hidden file called info2. W.E. won't show that, (or that info2 exists for that matter - even though I can see hidden and system files elsewhere) but shows you the original path/filename which it obviously pulls from the contents of info2. It shows me what it knows I want/need to see, but not what's really there.
And one other wierd thing I found in my testing.... I deleted a file from my desktop - C:\Documents and Settings\username\Desktop - but using cmd.exe and DIR, I found that file ended up in the recycler on the F: drive with all the correct path and details in that info2 so that it could be restored if necessary. Go figure.... Everything works as expected since Windows handles all recycle bins as one big recycle bin, but... that sure wasn't what I expected to see.
The more I experience of Windows, the more inexplicable it appears
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...
Shodan, On my XP system, the "Send To" folder really does have both the read only and hidden attributes set and when I copy it to some other location those attributes copy too. So I can see that CCleaner might be cautious about deleting a folder with either (or both) attributes set - although it does delete files set as RO as expected. And in fact, in a command window under XP here, if you try to delete a folder with the RO attribute set, it warns that it's read-only and asks if you want to continue - but still doesn't delete it if you answer Y. If you try that with a file set as read only, it simply refuses although Windows Explorer will warn and then move it to the recycle bin. Obviously, Windows (and a cmd window) does handle that RO attribute differently and the cmd window won't let you delete read only folders - or files.
In Windows Explorer, if you try to delete a folder with the RO attbibute set, it again warns and asks for confirmaton, but will move it to the recycle bin if you say Y. But... having been warned and given the choice to continue, even though that folder is in the recycle bin with the RO attribute set, a manual empty of the recycle bin does remove anything you put there - including that folder with the RO attribute set. CCleaner may be tripping over the fact that even in the recycle bin, it's still a folder with the RO attribute set. I guess it depends on how CC is programmed to do the deletes on what's in the recycle bin or whether it fails to make an exception for bypassing deletes of RO folders when they're in the recycle bin. And that obvously changed between release 3.10 and 3.11. What I still don't understand is why the portable version works and the downloaded/installed version doesn't - since I'm told they're the same executables although the portable version doesn't look at the registry..
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, 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.
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.
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
to solve your problem might I suggest a SIMPLER solution? right click the recycle bin choose empty bin (or whatever rubbish the menu says I'm not currently on a PC)
Shodan, Since this particular XP Pro system seems to think that all folders are pseudo-read-only - at least according to Windows Explorer, even when the RO attribute is not set - I can't really do a valid test here. All folders do show up in the analyze for the recycle bin (but not those in %temp%), but folders are not deleted, whether or not they're in the recycle bin or in some place like %temp%. In the recycle bin, Info2 contents are set to empty but the folder itself is not deleted. In %temp%, any files are deleted but folders are not.
But I did some testing on my wife's XP Home pc (with appropriate caution) and found that CC 3.19 doesn't care if a folder has 'system', 'hidden', 'read-only', or any combination of the three attributes set when it's in the recycle bin. The short answer is that it's Windows XP Pro here not allowing CC to work as it should. But... that doesn't explain why version 3.10 still works, the portable versions work, and all versions downloaded and installed since 3.10 fail. It sounds like you're on a newer Windows release than I am, and your symptoms lead me to wonder if there is a list of 'special' names that CC ignores by design.....
Nergal, You're right of course, and that's exactly what I do when I end up with a folder that CC can't remove from the recycle bin. Right-clicking on the recycle bin and clicking on "Empty" works just fine - even if CC has left the recycle in in some weird state. Unfortunately, that's not a workable option here for all those other places which CC attempts to clean but leaves any folder behind. And again, dropping back to 3.10 works as expected. I'm sure it's a full time job changing CC to match where each new version (or patch) in Windows moves things, but it sure would be nice to figure out what changed between 3.10 and all later releases to create the problem this Windows install presents.
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.
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.
This deviates from the topic so may be irrelevant.
The OP was concerned with a folder that contained files, You are testing with a folder containing links.
Links are not the same as normal files which do NOT designate some other object.
I think I remember a topic in the recent past by one person that found when CCleaner was supposed to remove a desktop link it instead (or as well) removed the designated target.
If you test the melting point of a steel container the consequences would be affected if it held water or petrol
What a folder held may affect what can be done to if after the contents have been removed.
There is much that I distrust about the inner workings of Windows,
especially the Distributed Link Tracking which caused me grief until I stopped 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.
I have done this test and was NOT able to recreate this issue (see attachments below). This was however on a non-XP machine I will have to wait til monday to test it on a XP machine.
"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.
Shodan, It looks like you're in the same boat I am, and also looking for a paddle. I tried your test, both here on my primary XP Pro system and on my wife's XP Home system. Here, it failed because it was a folder and this system is weird when it comes to folders. On the other system it worked just as you'd expect it to.
"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.
The fact remains that you are talking about "certain folders" (Send To, Start Menu, etc.) which have special purposes and which contain links.
RunAmok's topic concerns general purpose folders and problems with general purpose folders may affect your special purpose folders but the reverse need not apply,
hence I view this as interesting but also a deviation.
The Distributed Link Tracking Service is by default Automatic and constantly monitors where files are held and where they are moved to.
It caused major errors and problems when trying to use Acronis to make partition image backups.
I had to disable the service to use Acronis.
Windows has so many hidden wheels within wheels, bugs, and vulnerabilities that I hesitate to depend upon a special folder as being an equivalent to a general folder.
RunAmok has just reported a difference between an XP Home and a XP Pro system.
I think I would add confusion if I report what 64 bit Windows 7 does,
and my malware defense system (Comodo) would want to block removal of these special folders anyway.
Could you be suffering an anti-malware defense action ?
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.