Sure, %appdata% does work on my German XP as well as %programdata% etc.
Many of the combinations of winapp2.ini are like "\local settings\application data\" or "My blabla" which has no set command under XP.
As I understand, the local settings\application data is the same as %localappdata% for Win7.
Thank you very much.
I was afraid that a batch script which used %APPDATA% would need changing to %ANWNDUNGSDATEN%.
I previously added to the beginning of my script
IF "%LOCALAPPDATA%"=="" SET LOCALAPPDATA=%USERPROFILE%\Local Settings\Application Data
and used %LOCALAPPDATA% to replace all instances of
%USERPROFILE%\Local Settings\Application Data
What was good for XP is now good for W7 as well.
Pleased to see that this should also resolve foreign language problems.
It might be a solution to create a set command "localappdata" for ccleaner under XP to solve the problem.
%LOCALAPPDATA% is not defined for XP, and I thought the same as you.
I recently suggested winapp2.ini needed to be fixed to accommodate this,
but have been assured that the variable does exist.
I am happy to assume that when CCleaner runs its code (written in 'C' I believe)
it is able to achieve the equivalent of SET LOCALAPPDATA=.....
and this additional environmental variable is inherited by Winapp2.ini when CCleaner runs it.
What kind of script are you working on?
I have taken a cleanup script from the Comodo user forum and made it bullet proof.
The original made the assumption that when it deleted something it was gone.
Often the assumption was good, but a lot of people had permissions issues which prevented deletion.
I have adapted the script to revisit everything it deleted and report every item that resisted eviction.
It makes no attempt at automatically over-powering Windows security settings and breaking down permissions barriers,
but it identifies every problem which merits consideration of manual actions to "take ownership" and then zap.
After various battles I had everything good for XP, for which it was written.
I have recently got dual booting and Windows 7.
I think M.$ used Intellectual property of others, possibly Unix, when they created JUNCTIONS.
They did not understand what the were doing and made a pigs ear out of what had been a silk purse.
They originally intended and published that when a JUNCTION was no longer needed it could be deleted.
Unfortunately deleting not only removed the junction it also removed the entire contents of the destination.
Instead of correcting their mistake they published a technical note warning of the problem
and as a typical M.$. bodgy workaround advise the use of CACLS to protect the junction from deletion.
Windows 7 (and presumably Vista) are supposed to be able to use applications that were coded for use on XP,
and to that end they have JUNCTIONS to intercept and redirect the paths that were present in XP.
Those morons still have not corrected their fundamental error,
and have applied special access restrictions to prevent deletion of the junctions in W7.
Unfortunately this has broken functionality for most of CMD.EXE,
e.g. DIR will not see files that are on the junction destination.
Now I have altered every path to make maximum use of environmental variables,
and have found that two of these variables are defined in W7 to avoid the redirection JUNCTIONS.
CMD.EXE now works just as well in W7 as in XP for cleaning two paths which no longer use JUNCTIONS.
I have quite a few more paths to correct and validate for W7 - but I am getting there.
Regards
Alan