Jump to content
CCleaner Community Forums

selukwe

Experienced Members
  • Content count

    14
  • Joined

  • Last visited

Community Reputation

0 Neutral

About selukwe

  • Rank
    Member
  1. OK. Given the above explanation, I guess, this topic has been exhausted.
  2. 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...
  3. 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.
  4. 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.
  5. 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?
  6. 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?
  7. 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...:-)
  8. 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?
  9. >> 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.
  10. 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.
  11. 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.
  12. >> 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.
  13. 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.
  14. 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.
×