I did some messing around, simply setting the Read only bit on a folder will make the folder unremovable in ccleaner. neither adding an include or adding the folder in winapp2,ini will cause the folder or any sub folders with the read only bit set to be removed, I would upload a batch script to allow you to test this for yourself do this however the form does not allow batch files so in the spirit of the rule I will not.
I consider this a bug because in windows "read only" does not actually mean read only, it really means read the desktop.ini used for special folders and icons, tool tips, symbolic links etc...
Is there any fix for this ? short of the clumsy solution of writing an external batch file to recursively remove the folder attributes before the folder is processed by ccleaner.
I consider this a bug because in windows "read only" does not actually mean read only, it really means read the desktop.ini used for special folders and icons, tool tips, symbolic links etc...
Um what? No, as far as I'm educated (which is quite quite far), read only means any user with matching security credentials can only open and view a file or folder; just as is true in any operating system. Where do you glean your understanding of the definition (link)?
Of course ccleaner can't clean read-only files, deleting is not reading.
@ Andavari : Of course, that's why I said in the spirit of the forms. but I have posted it as a text document.
@ Nergal : Sorry but I do have you on this one. "This sets the read-only bit on the folder to indicate that the special behavior reserved for Desktop.ini should be enabled." from
Keep in mind these folders are not locked, also you can check it yourself by setting an icon and then checking the folder attributes and or activate your own icon file from a custom desktop.ini as I do for portable icons that stick with the folder. I'll attach an example as well as a batch file that does it.
To use simply copy the `~` folder, and the desktop.ini to any other folder than drag that folder over "Make unremovable.bat" and volia you'll have an icon magically appear.
oh ps the desktop.ini is system hidden... so make sure that you can see those files if you want to play with moving them around.
I've known this for a long time going back countless versions, but I never thought of it as a bug.
So I take it there is no fix for this other than using an external scrpt ?
I have always known that ccleaner was not... well quite agressive enough in my view, for countless versions. but never really quite thought it was this bad.. basically if the folder has any custiomisations it will not be cleaned by ccleaner which in my view is riduculus. I have long wished they would borrow from the collomb file unlocker (or something simular) and add an option to make ccleaner more agressive when it came to deleting locked, system hidden, and read only files.
in most cases this shouldn't be a problem for an average user, but if I add an entry I feel ccleaner should remove it, or at least report an error "cannot remove file because" at the moment it silently leaves things behind.
While, personally, I disagree with you, the developers read a all suggestions, so maybe they will add something like that...I hope mot because of all the havoc that could cause (I have seen people add c:windows*.* recurse in their includes)
@ Nergal you're one of the brighter ones around here and I can't help but respect your point of view. Although I feel that while it's probably true that a determined fool can poke their eye out with a donut, that doesn't mean there shouldn't be donuts for those who want them.
I think options for that kind of thing and more information, such as reporting that files/folders were not removed and why is always useful.
and just to be cheeky, in my case c:windows*.*|recurse wouldn't do any damage as windows is not on my c drive .
thanks for the advice I will put something in suggestions.
@ Nergal : Sorry but I do have you on this one. "This sets the read-only bit on the folder to indicate that the special behavior reserved for Desktop.ini should be enabled." from
Use the following procedure to customize a folder's style with Desktop.ini:
Use PathMakeSystemFolder to make the folder a system folder. This sets the read-only bit on the folder to indicate that the special behavior reserved for Desktop.ini should be enabled. You can also make a folder a system folder from the command line by using attrib +sFolderName.
Create a Desktop.ini file for the folder. You should mark it as hidden and system to ensure that it is hidden from normal users.
Make sure the Desktop.ini file that you create is in the Unicode format. This is necessary to store the localized strings that can be displayed to users.
It is obvious from the above that PathMakeSystem Folder is responsible for creating a SYSTEM folder and for setting the read-only bit,
AND that this does not CAUSE special behaviour but merely signals that this is desired.
An alternative is NOT
attrib +r but
attrib +s
It is Desktop.ini that has special behaviour reserved for itself,
and there are two more clauses defining creation and properties of a Desktop.ini to create this special behaviour.
In no way is it saying that the read-only bit is reserved for customizing a folder's style,
and I see no justification for asserting that "read only" does not mean what it says
I consider this a bug because in windows "read only" does not actually mean read only, it really means read the desktop.ini used for special folders and icons, tool tips, symbolic links etc...