Jump to content
CCleaner Community Forums


Experienced Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About selukwe

  • Rank
  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 ef
  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
  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 i
  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 furt
  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
  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.
  • Create New...