Jump to content

Problem deleting folders delimited with % (\%*%\)


Recommended Posts

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

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

  • Moderators

%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

 

post-21882-0-94258300-1339099170_thumb.jpg

%fff% - Cleans

%appdata% - no clean

%programfiles%- no clean

post-21882-0-93578600-1339099171_thumb.jpg

 

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.

 

post-21882-0-40155500-1339099791_thumb.jpg

 

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

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 :unsure:

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.