Installers and dataloss
Since Slashdot and MozillaZine have kindly dredged up old quotes:
I still stand by my original opinion that the code to clean up completely on the uninstall is fine and useful if the install process is far less stupid. We shouldn’t allow installation into populated folders in the first place, unless we can establish that its an existing install location. Then we’re still free to nuke the folder afterwards, since we didn’t install somewhere stupid. Simply leaving crap behind is a kludgy solution and I while I did review the band-aid that eventually removed the call to clean up, its a hack that I don’t like. The suite has had the same function, for _years_ and I have never heard of someone nuking their hard drive using it.
Around 0.7, the installer would offer to clean up the destination folder before install, mirroring the feature implemented in the Suite for 1.5. This ensured that old extensions and cruft from previous versions didn’t break us. People complained long and loud about this, so we gave in and dropped it. Soon after, people discovered the same code was being called in the uninstall routine as well. Eventually (1.0.1) we gave in and dropped this too.
Now the current situation is that if something gets installed to the app folder, and its causing problems, doing a clean install requires that users navigate through Windows Explorer and manually clean up the install folder. Simply uninstalling and reinstalling won’t cut it, like so many other apps. At this point, we now have a self-extracting exe that adds some shortcuts and shows an EULA, and the uninstall is only somewhat useful. This barely qualifies as an installer in my book, and isn’t worth the time and effort invested in rolling our own installer instead of just using something off the shelf. The problem we face now is that we have a large existing install base with potentially damaging install locations, and we can’t put the genie back in that bottle.
Whatever solution we implement going forward for safer/saner installation, we still need a backwards-compatible solution. At the least, we need to mod the function that checks for leftover files to at least tell the user (we don’t even do that now). And if its an old installation (we’ll have to tag new installs somehow to make the distinction) we should provide a button to open the install folder in the user’s file manager. That’s the least we can do to ensure that users can easily clean up our mess.
“The suite has had the same function, for _years_ and I have never heard of someone nuking their hard drive using it.”
I think this is the third time I’ve responded to you saying something similar to this, but…
The suite’s installer makes it less likely that someone will install to somewhere they didn’t intend to (e.g. a folder they were intending to install into a subfolder of), because it allows you to view and edit the install path in the folder selection dialog.
Your opinion wasn’t wrong (IMHO), and there were a bunch of people saying that a better installation routine would be a reasonable solution to the uninstaller-nukage bug. But given that there wasn’t (and still isn’t) any sign of the installer work happening in the foreseeable future, the hack was the right thing to do (and should’ve happened sooner).
Vaguely related – I understand that the MSI builds are based on a kludge (using the MSI architecture to “install” the setup file and then running it), and have no useful uninstall. It may improve before a release, but if not, that sounds like another genie that’ll be out of its bottle.
AIUI (can’t remember where I got this from), the original reason for the roll-your-own installer was licensing issues.
Of course I agree with you. And if michaell is correct about the current msi, that’s sad. But it seems that everybody and his brother is using a standard Windows installer (it may come from Microsoft) for their software in the windows environment; why not us? I have zero experience running Linux, but it would surprise me if there were not a fairly standard installer for that OS as well.
OK, so the experience would not be the same across all the OS’s. Who cares? As long as the process followed one of the standard install patterns for that OS, users would be happy.
imho, the installer should force that the last dir in the path is the app name (i.e. mozilla/firefox/thunderbird, etc), this way no one can choose to install directly into program files, etc.. i’ve seen it before, not the most user friendly since u can’t modify the actual dir name of the program, but it’s definately the safest and will prevent all kinds of problems.
and while we’re talking about installers, here’s a 1.02 installer bug:
i had 1.01 running from zip ‘install’ (i.e. zip extracted to a dir and i run it from there). then i checked for updates, it told me 1.02 is a security update, i let it start the download, and then an installer started. since i don’t use installers at all with firefox, just looked when i clicked ‘custom’ and saw that the install dir is not the one from which the 1.01 was running. i canceled the process, and decided to download the zip version of 1.02.
that’s it. 1.01 refused to run anymore. each time i ran it a message that restart is needed to complete installation, and that’s it. clicking the ‘ok’ closed the dialog but didn’t kill the process.
eventually i HAD to run the 1.02 installer and it worked.
still, when i’m trying my old 1.01 it refuses to run with the same message as before….
quite annoying.
Well I have seen users complaining that Quicktime and other content not working after nuking the Firefox directory. Leaving the plugin folder there is kind of nice and haven’t seen anyone complain of problems due to dlls residing in that folder.
new york state mortgage broker…
…
clonazepam panic…
…