Serious uninstaller issue

[Das]

CCleaner has never had any issues running uninstallers correctly - AFAIK it takes no action of its own, but simply uses the Control Panel function.

I'll experiment some in a moment with a testing directory.
***
After experimenting with multiple variations, the only way I could replicate the issue was to force the installation into F:\_PROGRAMS. After that the uninstaller had absolutely no scruples about wiping everything in that directory, FAH or no - it even removed the _PROGRAMS directory in the end.

Based on the evidence, it's user error combined with very dangerous code. How about those safeguards?

[art_l_j_PlanetAMD64]

CCleaner has never had any issues running uninstallers correctly - AFAIK it takes no action of its own, but simply uses the Control Panel function.

Yes, I'm sure that CCleaner just has a better interface for the user, but the underlying method is the same as either:

• Start -> Run -> G:\_PROGRAMS\FAHClient\Uninstall.exe, or
• Start -> All Programs -> FAHClient -> Uninstall

I'll experiment some in a moment with a testing directory.
***
After experimenting with multiple variations, the only way I could replicate the issue was to force the installation into F:\_PROGRAMS. After that the uninstaller had absolutely no scruples about wiping everything in that directory, FAH or no - it even removed the _PROGRAMS directory in the end.

Do you mean F:\_PROGRAMS\FAHClient, or just F:\_PROGRAMS? Because if it's just F:\_PROGRAMS, then the uninstaller is doing exactly what it is programmed to do, which is to remove everything under the install directory, plus the directory itself. But if it was F:\_PROGRAMS\FAHClient, could you please record the precise sequence of events that cause this problem? I'd like to be able to find a repeatable sequence of events that give the same problem each time. I just looked, and both F: and G: that I used in my test are partitions on the same physical 2TB drive. I don't think it would make any difference, but I could create another partition in some unallocated space on another 500GB drive, and repeat the test. Perhaps it has something to do with the install/uninstall happening on different physical drives?

Based on the evidence, it's user error combined with very dangerous code. How about those safeguards?

I agree, and letting the user edit the first part of the path ("C:\Program Files"), but not the last part ("\FAHClient\") would do that without requiring too much effort. But it would still be good to find out exactly why the error occurred.

[Das]

Just _PROGRAMS, no FAHClient.

I tried to replicate the situation by switching between S and F drives, but I got sick of the reboots at some point, so this wasn't a 1:1 repeat of the process.

[art_l_j_PlanetAMD64]

Just _PROGRAMS, no FAHClient.

OK, that explains it, then. Having the last part of the path fixed as "\FAHClient\", would be a safeguard that would definitely eliminate this problem.

[Das]

PS. Windows' default backup function (not Restore Points, but the Previous Versions thing) restored files and folders perfectly with permissions intact! I heartily recommend people give it a try and use third-party backup programs with caution. The main thing here was that the Windows function could restore NTFS permissions whereas FBackup garbled those up, leading to unusable data.

Nothing more infuriating than seeing your files but being unable to use them (unless you take ownership one by one).

[bruce]

I added your suggestions to existing Ticket #107

[Matthias1999]

This just happened to me, is there a way to find what exactly it deleted?