Serious uninstaller issue

[art_l_j_PlanetAMD64]

Re: PATH

The value for that variable is currently blank in the user variables section.

This might explain the problem, if the FAHClient uninstaller did indeed use the user's PATH as the 'root directory' for removing all files, folders, and subfolders from "the directory where it was installed". Being blank might evaluate to "the root directory of the currently selected drive".

Out of curiosity I checked the System Variables list, and there is a "Path" variable there that has multiple values, a lot of them hardware-related like Nvidia's and Intel's software.

Yes, this contains the places where Windows looks to find a program when you run it from the command line. For example, 'C:\Windows\System32' is one directory in my %PATH%, so if I run the command 'calc' from the command line, Windows will find the file 'C:\Windows\System32\calc.exe', and run it.

[Das]

Thanks for explaining the system variable PATH - I'm only familiar with TEMP.

[art_l_j_PlanetAMD64]

I have looked through the Registries on 2 machines here, one Win7 and one WinXP, and the only reference to the FAHClient installation directory is in the user's private PATH environment variable. The WinXP user's PATH was different, though, here is its value:
%CommonProgramFiles%\Microsoft Shared\Windows Live;C:\Program Files\FAHClient

The WinXP Registry is the same (naturally) as the Win7 Registry regarding the Registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\FAHClient, where it has a DataDirectory value and an UninstallString, but no uninstall directory is listed.

I have set up my WinXP FAHControl/FAHClient to 'Finish' in about 3 hours, when the current SMP WU has been completed. I will then 'Quit' FAHControl/FAHClient, and create a dummy 'FAHClient' installation on another drive (D:\TestFAH\FAHClient). I will then change the user's PATH to the string "D:\TestFAH\FAHClient", and run the FAHClient uninstaller. This should conclusively prove whether or not the user's private PATH variable is used by the FAHClient uninstaller. I will report back when this test has been completed.

[Jesse_V]

This should conclusively prove whether or not the user's private PATH variable is used by the FAHClient uninstaller. I will report back when this test has been completed.

That's absolutely brilliant. Hopefully your experimental produces fruitful results.

You asked earlier if I thought this issue would be tied to the environmental variable. The answer is no, I wouldn't have guessed that. You win the prize for thinking of that, well done!

[bruce]

The uninstaller has to be able to uninstall any of the programs that have been installed using Microsoft standards in any order, not just the most recent one. The local PATH can't be the place that the uninstaller gets its information.

[7im]

Actually, why is there no dword and value for the uninstall directory? directories?

As of now, the "uninstaller.exe" seems to nuke everything in the currect directory where it is run.

[art_l_j_PlanetAMD64]

The uninstaller has to be able to uninstall any of the programs that have been installed using Microsoft standards in any order, not just the most recent one. The local PATH can't be the place that the uninstaller gets its information.

I agree, that that's how it is supposed to work, but how else does the uninstaller find the program directory to uninstall?

On my WinXP machine (and similarly on the Win7 machine), the Registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\FAHClient has only these values that have anything close to the required data (ie the install directory name):
DisplayIcon value: "C:\Program Files\FAHClient\FAHClient.ico"
UninstallString value: "C:\Program Files\FAHClient\Uninstall.exe"

The uninstall program was written by (I assume) someone at PG, so isn't there some possibility that a non-standard way of identifying the install directory was used?

Unless the uninstaller "C:\Program Files\FAHClient\Uninstall.exe" somehow extracts the install directory name from the DisplayIcon value or the UninstallString value, how does it know the install directory? And if it did that, why did Das have the problem we are trying to fix?

I have looked at a few other Uninstall Registry entries, and they have things like this:
InstallLocation value: "C:\Program Files\CCleaner"
InstallLocation value: "C:\Program Files\Creative\AudioCS"
InstallLocation value: "C:\Program Files\Creative\Shared Files\Software Update"

Again, I agree with what you said about how it should work. But the only thing I can think of to explain the problem based on the available evidence, is the hypothesis that the user's PATH was used to locate the program directory to be uninstalled. Anyway, in a little over an hour, I will be testing my hypothesis, and will be reporting back here.

...when you have eliminated the impossible, whatever remains, however improbable, must be the truth.
- Sir Arthur Conan Doyle, (Sherlock Holmes)

[art_l_j_PlanetAMD64]

Short answer: bruce was right (as always)!

Long answer: We now have absolutely no idea how the Uninstall.exe program did what it did to Das's computer.

It turns out that the Uninstall.exe program, in the absence of the 'InstallLocation' registry value, strips its own name from the command-line ("C:\Program Files\FAHClient\Uninstall.exe"), to get the uninstall directory ("C:\Program Files\FAHClient").

Running it like this:
Start -> All Programs -> FAHClient -> Uninstall
causes FAHClient to be removed from C:\Program Files.

Question for Das: Did you use the above method (Start -> All Programs -> FAHClient -> Uninstall), or did you perhaps use a different method like Start -> Control Panel -> Programs and Features -> Uninstall or change a program to uninstall FAHClient?
Question for bruce and Jesse: Would that make any difference if it was done that way, or would it still run the command "C:\Program Files\FAHClient\Uninstall.exe"?

Running it from the test directory "D:\TestFAHProg\FAHClient\Uninstall.exe" causes FAHClient to be removed from D:\TestFAHProg.

So we're back to square one on this one. The Uninstall program finds its own uninstall directory, and the data directory (if you choose to delete it) is found by the 'DataDirectory' value in the Registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\FAHClient.

The only possibility I can see, and it is extremely remote, is if the 'DataDirectory' value in the Registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\FAHClient was corrupted, and you were deleting the data. As far as I can see, there is literally no other way for the very simple uninstall process to go so wrong.

Does anyone else have any ideas?

[art_l_j_PlanetAMD64]

Hold on, there is one very logical way to explain what happened.

Suppose FAHClient was installed in the root directory, as Das said here:

Your comment made me wonder if I by accident installed the client in the root, in this case "E:\_EXAMPLE" instead of "E:\_EXAMPLE\Example" (E:\_EXAMPLE is the "root" directory for all secondary, non-OS software, i.e. E:\_EXAMPLE\MS Office), but I haven't made that mistake since about 2001. This is of course something to check when trying to reproduce the issue, and possibly something to code safeguards against - a to-delete file list perhaps, instead of a blind directory wipe.

The uninstaller would then, of course, do exactly what it is programmed to do. Namely, to delete everything starting from the root directory on down. This is absolutely the only reasonable way to explain what happened. I mean, in the "Choose Install Location" step, what if someone enters "C:\" instead of "C:\Program Files\FAHClient\"? Exactly what happened to Das, that's what!

So, this is something that the FAH installer should be prepared to handle, a user error that will have disastrous consequences during the uninstall process. It could check if the user-entered install path ended in "...\FAHClient\", and if not, automatically add the "FAHClient\" part that the user forgot. Problem solved!

[7im]

Hold on, there is one very logical way to explain what happened.

Suppose FAHClient was installed in the root directory, as Das said here:

Your comment made me wonder if I by accident installed the client in the root, in this case "E:\_EXAMPLE" instead of "E:\_EXAMPLE\Example" (E:\_EXAMPLE is the "root" directory for all secondary, non-OS software, i.e. E:\_EXAMPLE\MS Office), but I haven't made that mistake since about 2001. This is of course something to check when trying to reproduce the issue, and possibly something to code safeguards against - a to-delete file list perhaps, instead of a blind directory wipe.

The uninstaller would then, of course, do exactly what it is programmed to do. Namely, to delete everything starting from the root directory on down. This is absolutely the only reasonable way to explain what happened. I mean, in the "Choose Install Location" step, what if someone enters "C:\" instead of "C:\Program Files\FAHClient\"? Exactly what happened to Das, that's what!

So, this is something that the FAH installer should be prepared to handle, a user error that will have disastrous consequences during the uninstall process. It could check if the user-entered install path ended in "...\FAHClient\", and if not, automatically add the "FAHClient\" part that the user forgot. Problem solved!

Thanks for all the extra analysis, but I already said that yesterday.

The fah V7 uninstaller, currently by design, removes all files, folders, and subfolders from the directory where it was installed.

And the problem is not solved, if the donor selects a custom location like FC instead of FAHClient.

As I said before, the uninstaller needs to change. Instead of simply nuking the install directory, it needs to track each file and directory installed, and then remove only those files.

[art_l_j_PlanetAMD64]

Thanks for all the extra analysis, but I already said that yesterday.

The fah V7 uninstaller, currently by design, removes all files, folders, and subfolders from the directory where it was installed.

Yes, you explained what the uninstaller does, but I didn't see anyone explain how the whole directory structure on the E: drive started to be wiped. Except for Das, in his second message, but he said he was pretty sure that he had not done that (installed to the root directory).

And the problem is not solved, if the donor selects a custom location like FC instead of FAHClient.

I think it would be quite reasonable to tell the user that the directory name must end in 'FAHClient\'. Why would they need to make a custom name? Certainly it could be accommodated, but isn't that just extra work that the PG developers don't really need to do? Just my opinion.

As I said before, the uninstaller needs to change. Instead of simply nuking the install directory, it needs to track each file and directory installed, and then remove only those files.

Again, why make all that extra work for the PG developers? If the installer ensures that FAH is installed in its own directory, then all of that extra work would not be required. Nuking the install directory would be perfectly safe. That is what just about all third-party software does under Windows. It's in its own directory, and so it can safely be nuked.

[7im]

Why? So what happened to Das doesn't happen to anyone else. Maintaining a payload list of install files to uninstall isn't a monumental task. No, not as easy as what it currently does, but it can be done.

[art_l_j_PlanetAMD64]

Why? So what happened to Das doesn't happen to anyone else. Maintaining a payload list of install files to uninstall isn't a monumental task. No, not as easy as what it currently does, but it can be done.

What I suggested does the same thing, so that what happened to Das doesn't happen to anyone else. And it does not have the extra work for the PG developers.

[Rattledagger]

I think it would be quite reasonable to tell the user that the directory name must end in 'FAHClient\'. Why would they need to make a custom name? Certainly it could be accommodated, but isn't that just extra work that the PG developers don't really need to do? Just my opinion.

If users starts typing-in a non-default location, it's unrealistic to expect they'll remember to type "FAHClient" at the end and not something else, so this requirement doesn't make any sence. Also, even if user does take this into account, it's very easy to make a typing-errro, and if FAH can't handle this it's a serious bug.

Having the installer automatically adding "FAHClient" to whatever user types if calls it something else is a possibility, but should be unneccessary.

Having the installer refuse to install to certain directories on the other hand would be a good idea, example to install as "c:\program files\" instead of "c:\program files\fah-client" is a good requirement. Similarly, it should not be possible to install to c:\ nor anywhere under c:\windows\

[art_l_j_PlanetAMD64]

If users starts typing-in a non-default location, it's unrealistic to expect they'll remember to type "FAHClient" at the end and not something else, so this requirement doesn't make any sence. Also, even if user does take this into account, it's very easy to make a typing-errro, and if FAH can't handle this it's a serious bug.

1. That's not what I was suggesting, the "FAHClient" part would be fixed as the end of the path (the next suggestion below, #2).

Having the installer automatically adding "FAHClient" to whatever user types if calls it something else is a possibility, but should be unnecessary.

2. This is not exactly how it would work. If the user chose to make a custom install path, they could edit the first part of the path ("C:\Program Files"), but not the last part ("\FAHClient\"). I think this is the best choice, as it solves the problem and is the simplest overall (the KISS principle). This is very similar to what Windows Explorer does when you want to rename a file. If you want to rename "Myfile.txt", Windows Explorer tries to let you change "Myfile", but not ".txt" (yes, you can defeat this, but this is the default action of the Rename function in Windows Explorer). So this is consistent with what a Microsoft product already does.

Having the installer refuse to install to certain directories on the other hand would be a good idea, example to install as "c:\program files\" instead of "c:\program files\fah-client" is a good requirement. Similarly, it should not be possible to install to c:\ nor anywhere under c:\windows\

3. This would work but is much more difficult and time-consuming compared to option #2 (the KISS principle again). Determining "good" from "bad" paths is a much more complex job than simply ensuring that the path ends with "\FAHClient\".