CCleaner contains a bug that prevents delete of files/folders which nest inside a foldername where percent sign is used (example \%FolderName%\. As a standard, e.g. VMWare thin-apped applications use this convention to define their subfolder structures and temporary files. Regretfully, CCleaner ignores such paths and cannot delete files and folders inside. A quick fix would be much welcome, as well as further checking on deleteability of all allowed characters in file/folder names for the program to be able to act on all.
I cannot confirm this. I was perfectly able to remove and folder with the name:
%fff%
on both
windows 7 Ultimate sp1 Ccleaner 3.19.1721
and
Windows XP Professional SP3 CCleaner 3.18.1707
if you are using custom folders besure that you chose the correct setting
Was I correct in my folder's name or did you mean the folder's name is:
\%fff%\
It doesn't work neither on my Win 7 SP1 nor on WinXP SP3. I'm using the latest version of CCleaner. Other app (IE Privacy Keeper by Browser Tools) erases all as need be. My settings are set to delete files, subfolders as well as the folder itself. The path to delete is set OK - I just dragged it to CCleaner's window and adjusted the delete job appropriately. There is nothing that would specifically protect this path from deleting as also clean deleting with IE Privacy Keeper shows. The bad thing about IEPK is that it was last updated in 2005, though it still works surprisingly well...
You seem to have deleted \%fff%\ as the last folder. Have you tried putting some other folders with files nested still further? In my case, this is never the last folder to be deleted and other folders without percent symbol follow. I don't know why it works on your system and doesn't work on mine but the prog would be welcome with enforced delete function in cases of possible different behaviour.
The folder name I meant was e.g. C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\%AppData%\Temp\ etc.
I had no issue removing the folder with items in it
CLEANING COMPLETE - (0.345 secs) ------------------------------------------------------------------------------------------ 0 bytes removed. ------------------------------------------------------------------------------------------ Details of files deleted ------------------------------------------------------------------------------------------ Advanced - Custom Files and Folders 0 KB 2 files ------------------------------------------------------------------------------------------ C:\Users\Nergal\Desktop\%fff%\New Microsoft Word Document.docx 0 KB C:\Users\Nergal\Desktop\%fff%\New Text Document.txt 0 KB
My Guess is (rightfully) thinstall is protecting your folders
>> My Guess is (rightfully) thinstall is protecting your folders...
I'm not sure this is the case. How come then that IE Privacy Keeper has no problem with this...-?
But maybe CCleaner is hardcoded to behave like this. If it is then this is a bad idea as the user should be able to override this when he wants or needs to.
can't answer that as I only use IEPK to remove IE files and have even thinned the amount of those down as it was causing IE Cache corruption 9/10 time it cleaned
I'm almost not using IEPK now having switched to CCleaner but having encountered the above problem I tried it only to find out that in this it behaves faultlessly. I still think CC should be set to simply enforce any stubborn delete... By any I mean really any and all.
The folder name I meant was e.g. C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\%AppData%\Temp\ etc.
You should have told the truth in your first post
There is a world of difference between "\%FolderName%\" and "\%AppData%\"
Both can be understood as Envirnmental variables
The first is not normally defined
The second is conventionally something like
"C:\Users\Alan\AppData\Roaming"
i.e. your folder name could be interpreted as
C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\C:\Users\Alan\AppData\Roaming\Temp\ etc.
Perhaps Thinstall gets confused.
Thinstall doesn't get confused, it performs OK, no problems. But maybe it confuses CC with its convention used.
CC shows the path correctly as it is. Moreover - the path cannot be adjusted manually, you either drag and drop it or set it through the browse button without any manual interference as it's read only in the edit. Any idea what workaround could be made to make this work? Why does IEPK see the path correctly and deletes all as need be but CC cannot? Maybe some adjustment in CC would sort this out so that it would read the selected path as it is - not interpreting the variable further but accepting it as an exact path.
% is known as a Poison Character when using CMD.EXE
64 BIT Windows Ultimate + SP1 GETS CONFUSED.
Thinstall are idiots for doing this in Windows.
Microsoft are idiots for letting this be done to Windows.
I suspect the problem applies to all versions of Windows, and both 64 bit and 32 bit (and probably 16 bit if you can find it)
I created a folder D:\TEST\X\
I launched CMD.EXE and ran two commands as below
D:\Test>md d:\test\x\%appdata%
The file name, directory name, or volume label syntax is incorrect.
D:\Test>echo d:\test\x\%appdata%
d:\test\x\C:\Users\Alan\AppData\Roaming
D:\Test>
The first command is illegal and CMD.EXE error status is "syntax is incorrect"
The second command shows that "d:\test\x\%appdata%" is understood as a path that starts at drive D:\ and inexcusably jumps to drive C:\
You cannot have a path jump between drives without using reparse points.
Using Windows Explorer I was able to create a folder with the name %AppData%
I clicked and entered into this new folder
The attached image shows three overlapping instances of Windows Explorer
The top shows the "Address Bar" only which displays the path to "%AppData%" in the weird breadcrumb fashion of Win 7
I clicked in the address bar and the display changed to "d:\test\x\%appdata%" and I used Ctrl'C to copy into my paste buffer.
Below this is an address bar to "x" above a display of a folder named %AppData%
Below this is an Address Bar which I aimed at the root of D:\, and then Ctrl'V to copy the paste buffer into the address bar.
Windows allowed me to do that BUT the instant I hit ENTER then Windows went as far as it could,
i.e. you can see below the address bar it has selected folder "x"
BUT THEN Windows Explorer blows a fuse
it can't find D:\Test\x\C:\Users\Alan\AppData\Roaming
Well, that is no surprise to me.
I regret to say that Windows Idiotsyncrasies are no surprise to me
Yes I know Idiotsyncrasies is not the conventional spelling, but it feels appropriate.
If CCleaner is adjusted to deal with %APPDATA% as a literal text string and fail to expand it as a variable,
then hundreds of WinApp2.ini items will malfunction on this alone,
and there are probably thousands of others that would fail such as %WinDir%
I wonder what other applications and tools might malfunction with this foolish use of %.
Can your malware scanner penetrate illegal syntax folders and hunt down any malware ?
Can you be sure that your backup systems will penetrate and preserve any precious information held within illegal syntax folders ?
Regards
Alan
>> Can your malware scanner penetrate illegal syntax folders and hunt down any malware ?
It can handle thinapp-created folders, this doesn't seem to be a problem. I tested this with NIS and ESET. Also my backup prog doesn't misbehave.
With your conclusion, if it really is the way you describe it, then the only solution would be to use for thinstall-alike paths progs like IEPK, which do not have this variable interpretation problem.
ok this all makes sense now I'm win 32bit, IEPK is win 32bit. ccleaner you are running is 64bit, yes?
if Alan is correct about
64 BIT Windows Ultimate + SP1 GETS CONFUSED.
that's why, try and run the 32bit ccleaner, you can pull it from the portable zip of ccleaner) I bet it'll clean the folder
I don't think this makes sense. My Wins (both XP and 7) are both 32bit. How on earth could I run in them a 64bit app?
I apologize, as I am not in front of your computer I was unable to magically know the bit flavor of your pc, as you did not protest when Alan mentioned 64bit I made, what I felt was the proper guess that you were 64bit.
or do you not realize the complete lack of information you are presenting on a thus far un-recreatable bug?
either find a way for someone to recreate this, or it won't be able to be "fixed"
I think Nergal was addressing me.
My test shows that CMD.EXE refuses to recognise "d:\test\x\%appdata%"
and Windows Explorer cannot accept such an invalid path in the address bar.
I will try both the 32 bit and 64 bit versions of CCleaner on a suitable invalid path.
I will probably do it tomorrow.
I have just had a tooth removed by the dentist,
and I do not wish to finish of my day by losing all of %APPDATA% should CCleaner make the variable expansion that I anticipate.
I apologize, as I am not in front of your computer I was unable to magically know the bit flavor of your pc, as you did not protest when Alan mentioned 64bit I made, what I felt was the proper guess that you were 64bit.
or do you not realize the complete lack of information you are presenting on a thus far un-recreatable bug?
either find a way for someone to recreate this, or it won't be able to be "fixed"
I don't think this is appropriate. As Alan_B presented in his long contribution, this is the way CC has been hardcoded to perform, and to do what I'm after I obviously have to resort to other cleaners, e.g. IEPK (until it works). The whole point as I see it now is that CC interpretes variables in paths but IEPK (and perhaps some others as well) treats them as literal strings. While the first option is what is generally required, I also need the other part of the job done where using both one after the other solves my problem...:-)
Please note that I have confirmed NOTHING about the behavior of CCleaner.
I have ONLY pointed out that CMD.EXE is totally incapable of dealing with %APPDATA% as a literal string,
and Windows Explorer seriously misbehaves.
I have also pointed out that WinApp2.ini makes extensive use of variables which need to be expanded.
In my opinion CCleaner is correct in how it deals with invalid paths that include \%APPDATA%\ but I have yet to test and report the exact results.
I have now tested operation of both CCleaner.exe and CCleaner64.exe
No significant difference and no surprises (to me at least)
I created two files named set.txt and set.lst and placed them on two paths thus :-
C:\Users\Alan\AppData\Roaming\##\#1\%APPDATA%\##\#2\Set.Txt
C:\Users\Alan\AppData\Roaming\##\#2\Set.Lst
I launched Windows Explorer and aimed it at E:\
into the address bar I pasted
%APPDATA%\##\#2\
As I hit Enter the bar
displayed
C:\Users\Alan\AppData\Roaming\##\#2
and it showed the contents as Set.Lst
This satisfied me that if CCleaner "restarted" the path at %APPDATA%\##\#2\ then it would delete the wrong thing but not damage my system
I pasted into the address bar
C:\Users\Alan\AppData\Roaming\##\#1\%APPDATA%\##\#2\
And it responded (as expected)
Windows can't find
'C:\Users\Alan\AppData\Roaming\##\#1\C:\Users\Alan\AppData\Roaming\##\#2\', Check
the spelling and try again.
Crunch time :-
I used Portable CCleaner v3.19.1721
I launched CCleaner64.exe and selected Options => Include
I aimed Explorer at
C:\Users\Alan\AppData\Roaming\##\#1\%APPDATA%\##\
I drag-dropped the content #2 into CCleaner and it displayed
C:\Users\Alan\AppData\Roaming\##\#1\%APPDATA%\##\#2\*.*
I clicked Edit and the options were set to "Include Files Only"
I selected "Include files, subfolders and the folder itself"
I clicked O.K. and was warned the folder would be emptied, I clicked YES
Target display unchanged - still
C:\Users\Alan\AppData\Roaming\##\#1\%APPDATA%\##\#2\*.*
I unchecked every box under Windows and Applications
Ticked the "Custom Files and Folders"
Clicked Analyze
took 0.060 secs to announce 0 bytes removed
Clicked "Run Cleaner"
Took 0.047 seconds to announce 0 bytes removed
Closed CCleaner64.exe
CCleaner.ini held
Include1=PATH|C:\Users\Alan\AppData\Roaming\##\#1\%APPDATA%\##\#2\|*.*|REMOVESELF
I launched 32 bit CCleaner but it switched and I saw announced ...(64 bit)
I Renamed CCleaner64.exe as CCleaner64.exe.txt
I launched 32 bit CCleaner and that is what I got
The existing CCleaner.ini cleared ALL check boxes other than "Custom Files and Folders",
and Include target set to C:\Users\Alan\AppData\Roaming\##\#1\%APPDATA%\##\#2\*.*
I clicked Analyze
took 0.061 secs to announce 0 bytes removed
I clicked "Run Cleaner"
Took 0.048 seconds to announce 0 bytes removed
Closed CCleaner32.exe
...\#2\Set.txt survived as I expected
...\#2\set.lst was not a victim of Collateral damage.
CONCLUSION :-
Both 32 bit and 64 bit CCleaner correctly deal with valid Environmental Variables,
and they both refrain from deleting anything specified by an invalid syntax
N.B.
%APPDATA% is valid
\%APPDATA% is NOT valid - it expands to
\C:\Users\Alan\AppData\Roaming
e.g. - from a CMD.EXE screen
C:\Users>cd \%APPDATA%\##\#2\
The filename, directory name, or volume label syntax is incorrect.
C:\Users>cd %APPDATA%\##\#2\
C:\Users\Alan\AppData\Roaming\##\#2>
The title of this thread is wrong.
The complaint is due to the use of an Environmental Variable that commences with a specific drive such as C:\,
in which case preceding with \ is a syntax error.
Nergal correctly tested with an undefined %fff% hence there was no problem.
Thanks, Alan_B, you've done a great job.
But what's the general practical implication - is there a way how my path could be manually edited in the CC INI file so that CC would read it as a literal string and correctly remove the files/folders at its end? By my path I mean exactly (example):
C:\Documents and Settings\UserXY\Application Data\Thinstall\SomeProg\%AppData%\Temp\ .
%AppData% here is the real name of the folder created by Thinstall. There is no sense to manually rename it as it will be recreated next time by Thinstall using the hardcoded convention it uses. So this path is what exactly gets stored in the INI file when I drag and drop the last (=Temp) folder in the CC Include mode. I do not want anything in this path to be expanded, I just need CC to go after this literal path. Is there a way how this could be done by somehow manually tweaking the CC's INI file?
I have an answer - but you will not like it
You could place this simple *.BAT script in the same folder as CCleaner.exe and run the script to launch CCleaner
SET APPDATA=
SET APPDATA=%APPDATA%
START CCLEANER.EXE
EXIT
The intended result is that when CCleaner is running the variable %APPDATA% will no longer be expanded as
C:\Users\Alan\AppData\Roaming
but will after expansion be a simple literal
%APPDATA%
and this avoids the syntax error caused by
\C:\ etc.
All effects of the script are confined to the activities of CCleaner.exe and will end when CCleaner closes
UNWANTED RESULTS - UNKNOWN
BUT
Any cleaning performed as a result of WinApp2.ini could misfire for any items that use %APPDATA%
CCleaner.exe itself could misfire if it depends upon %APPDATA%
If you go this route I strongly suggest a close examination of the Analyze results before cleaning in case the APPDATA change causes unexpected damage.
A quick search gave me this result which relates %APPDATA% with Thinstall Sandbox
http://communities.v...m/thread/154505
Do Sandboxed or Portable applications need the benefit of CCleaner ?
Could you get advice from http://communities.vmware.com upon Thinstall option switches etc that would avoid this "\C:\" syntax error ?