selukwe Posted June 3, 2012 Author Share Posted June 3, 2012 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. Link to comment Share on other sites More sharing options...
selukwe Posted June 7, 2012 Author Share Posted June 7, 2012 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... Link to comment Share on other sites More sharing options...
Moderators Nergal Posted June 7, 2012 Moderators Share Posted June 7, 2012 %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 ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF. Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark) ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T. Support at https://support.ccleaner.com/s/?language=en_US Pro users file a PRIORITY SUPPORT via email support@ccleaner.com Link to comment Share on other sites More sharing options...
Alan_B Posted June 7, 2012 Share Posted June 7, 2012 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 Link to comment Share on other sites More sharing options...
Alan_B Posted June 7, 2012 Share Posted June 7, 2012 Oops. Ninja'd by Nergal again Link to comment Share on other sites More sharing options...
selukwe Posted June 7, 2012 Author Share Posted June 7, 2012 OK. Given the above explanation, I guess, this topic has been exhausted. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now