I'd love to have this as a solution but ...it doesn't work. CC still doesn't touch this path.
Any idea what might be wrong?
My first thought is that your Thinstall Application may have the deletion target, i.e.
C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\%AppData%\Temp\ etc
either still in use (e.g.App running or a CMD.EXE instance etc. sitting in the deletion target folder),
or perhaps it has set access restrictions.
The above is proven if you use Windows Explorer to navigate towards the deletion target folder and are unable to successfully delete it.
Alternatively perhaps when %APPDATA% is absent or wrongly defined then CCleaner "just curls up in a ball and wants to die",
A DIFFERENT AND UNTESTED SOLUTION
It will be another day before I can test and debug,
but you might like to copy the script below into the CCleaner folder and try this.
SET APPDATA-SYS=%APPDATA%
SET APPDATA=
REN "C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\%AppData%" [APPDATA]
SET APPDATA=%APPDATA-SYS%
START "" /WAIT CCLEANER.EXE
SET APPDATA=
REN "C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\[APPDATA]" %AppData%
ECHO INSPECT THE SCREEN ABOVE FOR ANY ERRORS AND REPORT TO FORUM
PAUSE
EXIT
if you are using custom folders be sure that you chose the correct setting
Hi selukwe, forgive my intrusion, but I thought it worth checking as to whether you have any other CCleaner "Includes" running successfully.
The reason I ask is that if you don't, to simply check that you have the "Custom Files And Folders" box checked in "CCleaner\Windows\Advanced".
The obvious has been missed in threads before, and this setting, although alluded to by Nergal in his quoted post above, hasn't been mentioned or confirmed anywhere in this thread.
Just a thought.
Thanks Dennis - I concur.
N.B.
My latest script will require that when CCleaner runs you need to navigate to purge
C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\[AppData]\Temp\ etc.
AND NOT
C:\Documents and Settings\User\Application Data\Thinstall\SomeProg\%AppData%\Temp\ etc.
Hi selukwe, forgive my intrusion, but I thought it worth checking as to whether you have any other CCleaner "Includes" running successfully.
Yes, I have quite a few of them and they all run OK. Problem is only with the path with the mentioned variable, that obviously gets expanded and as a consequence the whole path is ignored.
Alan,
Many thanks for your well meant efforts and support but even all this doesn't work and I give up attempting to solve this problem by add-on scripts that could have other undesired and even unnoticeable side effects. Both paths with my variable return errors on attempt of their renaming but even worse is that the original app (or apps - as there may more thinapped apps in use) has to be closed for the path to be released for rename in the first place.
There are too many ifs and conditions for CC to do for me what I want. Frankly, this is thin ice and I prefer more straightforward solution and will stick to IEPK, which smoothly deletes the existing and literal paths, which the user has configured using the particular settings of the given PC. I really don't like the way how CCleaner approaches this, regardless whether this is by design or by some bugs. How come then that IEPK has no problem with this - after all thinapped programs are pretty widespread nowadays and there are hundreds of such applications around. I have to admit, regretfully, that performance of CC has disappointed me in this.
I now tend to believe that interpreting %AppData% as a variable instead of a literal string could be a bug in CCleaner.
Why do I think so?
Well, a similar type of string %ProgramFilesDir% in another program is treated like a literal string and CCleaner correctly removes everything that has been set within this path, this being a real path and not an expanded variable. I do not have anything to be removed within the path C:\Program Files\MyProgram\ and the path C:\Documents and Settings\User\Application Data\Thinstall\MyProgram\%ProgramFilesDir%\TempData\ is seen and acted upon by CC effectively and as it should.
Maybe some CC developers could shed some light on this... Do they read these forum exchanges? I'm sure this may be of concern of many users of VMWare ThinApp packaged programs who concurently want to take benefit of CCleaner...
%ProgramFilesDir% is not a valid Enviromental Variable so yes, CCleaner does not see this as a variable string. The Variable string you're looking for is %programfiles%, see below
Here are file results from using Include folders
%fff% - Cleans
%appdata% - no clean
%programfiles%- no clean
Thesis: Thinstalls don't expect to be cleaned, they are there to portablize and non-portable program. CCleaner cannot see through folders named as enviromental variables. This is not a bug. It is IN CCLEANERS DNA to read EV's as EV's.
AFAICT IEPK does not use EVs it uses literals and has a section for changing the default location of things. This is not a route that I think CCleaner should use as it makes it more of a chore for those people who causually use ccleaner and for those people who use ccleaner portably.
The Developers read all threads, and rarely if ever comment, nor, IMHO, should they need to in this case. They have made some in-roads into allowing some custom locations for items that use #specialdetec/key as their cleaning method
e.g.
[Mozilla - Internet History] ID=2002 LangSecRef=3026 LangRef=3162 Default=True SpecialDetect=DET_MOZILLA SpecialKey1=N_MOZ_HISTORY
however I don't think they would do this program wide as Special* seems to take much more programming than normal keys do
Well, a similar type of string %ProgramFilesDir% in another program is treated like a literal string and CCleaner correctly removes everything that has been set within this path, this being a real path and not an expanded variable..
NO.
There are no expanded variables but there are a few environment variables that can be expanded.
environment variables are commonly used with % ( or ! ) surrounding them
but strings surrounded by % (or !) are NOT variables unless they have been defined.
%ProgramFilesDir% MAY be an environment variable BUT ONLY if it is defined,
and if it has not been defined it CANNOT be expanded and therefore it can only be treated like a literal string by CCleaner
By default the XP Windows system defines variables such as
%PROGRAMFILES% and %APPDATA%, but
%PROGRAMFILESDIR% is NOT defined by Windows.
see
http://best-windows....-variables.html
If you launch CMD.EXE and type the command SET it will list the non-dynamic environment variables
(i.e. not %TIME%, %DATE% etc.)
SET will show you amongst other things
ProgramFiles=C:\Program Files
So far as Windows and therefore CCleaner are concerned there is no such variable as
%ProgramFilesDir%
I deduce that Thinstall-VMWare start with an application "MyProgram" which has code etc located in
C:\Program Files\TempData\
To portablize it a competent Thinstall developer has defined the variable
ProgramFilesDir=Program Files
hence what you and Windows and CCleaner see as being the VALID and literal path
C:\Documents and Settings\User\Application Data\Thinstall\MyProgram\%ProgramFilesDir%\TempData\
would be seen by the portablized Thinstall application as being based at
\%ProgramFilesDir%\TempData\
and this has a variable which the Thinstall layer expands to
\Program Files\TempData\
With suitable competence a Thinstall developer refrained from (ab)using the existing variable %ProgramFiles% which would expand into an illegal path,
and created his own special variant that had no previous definition and ensured nothing was illegal in any situation.
There must be a reason why another thinstall developer would defy convention and misuse in such a fashion.%APPDATA% which already had legal validity
I can think of several reasons but I think I have said enough already
Oops. Ninja'd by Nergal again
OK.
Given the above explanation, I guess, this topic has been exhausted.