Closed Bug 228672 Opened 21 years ago Closed 21 years ago

Installer deleted unrelated folders

Categories

(Firefox :: Installer, defect, P2)

Product:
Firefox
Component:
Installer
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox1.0beta

People

(Reporter: mozilla, Assigned: bugs)

References

(
URL
)

Details

(Keywords: conversion, dataloss, relnote)

Attachments

(1 file)

Uninstaller screencap
31.57 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/7.02 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Downloaded the firebird installer from Dec 11th and ran it. I accidentally installed to d:\internet when I wanted to install to d:\internet\MozillaFirebird. The install ran and installed Firebird, but it also deleted several folders in d:\internet, including Thunderbird (d:\internet\Thunderbird) and Netscape 4.7 (d:\internet\Netscape). Sorry, haven't tried to reproduce this, it is just too destructive. Reproducible: Didn't try Steps to Reproduce: 1. Run installer. 2. Install to a folder that contains other folders, such as a Thunderbird install. Actual Results: Thunderbird folder is deleted. Expected Results: No folders are deleted, except possibly an existing Firebird install. Before trying the install, I had renamed the previous version from d:\internet\MozillaFirebird to d:\internet\MozillaFirebird-0.7. After the install, the only three folders left in d:\internet were MozillaFirebird-0.7 (previous version), d:\internet\Mozilla (Mozilla suite 1.4) and d:\internet\MozillaFirebird (new install). I had also copied the whole Phoenix profile folder to make a backup, but there didn't seem to be any problems there.
This is going to lead to really bad press if people end up accidentally wiping out part of their hard drive (I know at least one person who installs a lot of programs straight into D:\Program Files). So setting block 0.8? flag.
Flags: blocking0.8?
-> New. blocking 0.8 Deleting the Program Files is one of the worst experience we could give to the user.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking0.8? → blocking0.8+
targeting.
Status: NEW → ASSIGNED
Target Milestone: --- → Firebird0.8
Actually, this is harder than it seems, AND: - This bug only manifests if you've installed the FB executable and other DLLs at the same level as a bunch of other files... something which is not good. Reasons why this won't block 0.8: - This bug has existed in every version of Seamonkey's installer since day 1 I think. - Firebird hides folder selection better than Seamonkey from novice users (it is not a part of the Standard install) These are not reasons to never fix this bug, just reasons why I can't prioritize this now. Minusing, retargeting to 0.9.
Flags: blocking0.8+ → blocking0.8-
Target Milestone: Firebird0.8 → Firebird0.9
Adding relnote keyword.
Keywords: relnote
> Reasons why this won't block 0.8: > - This bug has existed in every version of Seamonkey's installer since day 1 Ben, seamonkey installer only wipe the install folder when it already contains a previous installation. And even, it warns the user that the folder will be deleted. Firebird installer wipe the folder no matter if there is or isn't a previous installation and without warning the user. The fix is straightforward: like seamonkey, if there is no previous installation don't delete the install folder. Then at the next install in this directory, the user will have to confirm to delete all the files in this directory. Bonus if you add a warning that it is not safe to install Firebird in a directory (in which Firebird installation has not been detected) that is not empty. But we should at least have seamonkey parity for 0.8. The bug reporter wouldn't have been affected.
Shipping 0.8 with a bug of this magnitude is just unacceptable. At the very least it should alert the user that all files/directories below the chosen install directory will be deleted. comment #6 says that it should detect a previous installation... why cant the install do that? It shouldn't really be all that hard to do.
Seems like several people already been affected by this.
URL: http://forums.mozillazine.org/viewtop...
It seems to be a win98 only problem. With my own WinXP-Sp1 computer, no problem at all.
Keywords: dataloss
I have never wiped out anything with a custom install to a new directory C:\Program Files\MozillaFirebird\ with DOMI Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ I'd need to see exact steps on how to reproduce this.
alanjstr: 1) Download Installer version of Firebird 2) Install to C:\Program Files\MozillaFirebird 3) Install, or just copy any other files to C:\Program Files\MozillaFirebird 4) Try reinstalling Firebird Actual Result: Added files/dirs are removed. Imagine what will happen if one will install Firebird (stupid, i know) to C:\Program Files.
Hm...luckily I haven't recommended FB to my family who are still on Win98. :S This sounds really important, although I do wonder, why if this bug has existed in Seamonkey, that it was not detected till now? Weird.
John Lee: There is no problem if you install it in a directory of its own e.g. C:\Program Files\Firebird. There is a problem if you install it in a shared folder e.g. C:\Program Files or C:\Windows. Also, the default install will not do anything like that. Its only if you do a custom install, and then make it share a folder with other programs...
One solution could be to have a list of files installed by the installer and then when uninstalling, delete only the files created by the installer.
I agree that it should (a) attempt to Uninstall using the same method in Add/Remove and (b) have a manifest of files to delete in the case of app-dir extensions. Items from (b) would be presented as a list of "The following files are probably safe to delete..."
This bug seems awfully dangerous to leave in .8. Couldn't we disable Custom Install in .8 as a workaround, and leave really fixing this until .9? Seems like the only sane way to ship .8 safely, and in a reasonable period of time.
Sorry for the bugspam, but it seems someone has reproduced this bug on Windows XP SP1. More info at http://forums.mozillazine.org/viewtopic.php?t=42018
I can confirm this same behavior on Windows 2000 SP4 Simple Test 1) Create new directory d:\test\ 2) Copy random files/folders to d:\test\ 3) Run Installer -> Chose to install to d:\test\ Results: Everything below d:\test\ is deleted
Confirming the same behaviour on Windows XP Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031218 Firebird/0.7+ OS: Windows XP SP1 Steps to reproduce 1) create new folder C:\tmp\test 2) copy some junk into C:\tmp\test 3) create new folder C:\tmp\test\moretest 4) copy some more junk into c:\tmp\test\moretest 5) run FirebirdSetup from 0.8 branch 6) choose to install to C:\tmp\test 7) watch as all files and folders in C:\tmp\test are deleted! If a critical dataloss bug like this doesn't block 0.8, someone needs their head examined.
Possible workaround for 0.8: Add a warning to the installer that FB must be installed into it's own subdirectory (with an example like "C:\Program Files\Firebird") and not into a directory containing other files ("like C:\Program Files"), as it may cause problems during uninstall. Add a warning to the uninstaller that uninstall should not be performed if there are files unrelated to FB stored in the same directory. These would presumably be dead simple patches; I would have a go myself, but I don't have anything approaching a windows build environment, or time to set one up.
Sorry for the bugspam, but due to the latest waves of confirmation on other Windows-based OSes, I want to see if we can get this re-evaluated as blocking 0.8.
Flags: blocking0.8- → blocking0.8?
Ben: > Reasons why this won't block 0.8: > - This bug has existed in every version of Seamonkey's installer since day 1 I > think. A similar bug has existed in Seamonkey's installer only since 1.5alpha but that's not quite so serious. To trigger it with Seamonkey's installer, you have to install into "c:\program files" (or wherever), and then install a second version over the top and confirm that you want to delete the files. Firebird's installer doesn't check to see if there's an existing install in there first, so you can nuke stuff on the first install. (There's also the quite similar Linux bug 69153, which has been around forever) A possible workaround - instead of having the user select the actual install folder, have them select a path and then create a folder under the one selected. Quite a few installers I've seen do that.
Hm...then perhaps a new RFE for such a thing?
What about creating a file with a list of installed files and removing these one by one and the dirs if they're empty. Additionally RFE about old Mozilla/Firebird installations would be needed. Of course it requires changes to xpinstall.
This bug bit me lastnight, trying to install on Windows XP SP-1. I Tried to use the same install path I've always used for zipped builds, G:\, figuring the installer would simply add the "MozillaFirebird" sub-directory. The result was almost all data lost on G:\ Fortunately, I keep Win XP on it's own partition, and had done a good backup the night before. I'll be saddened and will lose some respect for this project if this bug is allowed into 0.8.
Another solution, add always a "MozillaFirebird" directory to the end of the path entered by the user. Add this directory if the user modified the default path. Ben, please read the reports of users loosing files in the forum. Lossing data is never nice. I'm sure you can help making the installer more user-friendly and stop this serious data loss. Don't just say "your files are gone because you never read the release notes". People will be angry if 0.8 final delete their files. Peace
the decision was already made by ben to minus this blocking flag. Unless hyatt overrules ben, the decision stands.
Flags: blocking0.8? → blocking0.8-
The original decision was made based on the incorrect assumption that this bug is unimportant and not easily duplicated. It has been proven that the installer makes it very easy to cause major dataloss, and that the fault ultimately lies in the installer logic and not the actions of the user. Respectfully request that you leave the blocking flag open (?) for someone with authority over this bug (hyatt) to make an updated decision in Ben's absence. If this remains closed (-) and targeted for Firebird 0.9 it may slip under the radar of the developers if a push is made for a Firebird release candidate. Please also note that Ben claims to not read bugmail, hasn't responded on the MozillaZine forums, and is supposed to be on vacation at this time. Proposed solutions: 1) If the user selects a directory to install to that does not contain any Firebird components but contains other directories or files, add a "MozillaFirebird" directory at the end of the install path in the UI. This is standard behavior for installers which allow the user to choose an installation directory. 2) Do not delete any folders not related to Firebird. The list of folders is small (chrome, components, defaults, plugins, res, searchplugins, uninstall) and should be easy to encapsulate and maintain. 3) If installing to a directory that contains DLL and EXE files, only delete as many files as would be necessary for a successful clean installation. EXE, DLL, LOG, CHK should be safe. Leave everything else alone (TXT, LNK, BAT) that might be important to the user and won't affect the integrity of the new installation at all.
Flags: blocking0.8- → blocking0.8?
Ben set it to - and - it will stay until Ben decided otherwise.
Flags: blocking0.8? → blocking0.8-
alanjstr beat me to it. No one except ben or hyatt can undo the minusing, regardless of how anyone else feels about it. Bugzilla and especially Firebird are not democracies. I am already going to email hyatt about this since it seems like the only way to make a decision final.
Along with what I put in comment 15, I think it should say "preparing to delete everything in c:\foo" at a minimum. mconnor concurs on that.
It's Ben's call.
I also don't think that this bug can make it to a milestone. firebird would get very bad press... and such a bad reputation is hard to lose. In my opinion this bug is really serious. if someone doesn't work the way it should be - well ok - but if it deletes your work environment - nah! I agree one should install Firebird into its own folder, but anyways. I think the most simple fix would be to let the installer create a default Firebird Directory on its own in the location specified (though i don't like the idea of not being able to name the folder the way i want).
I agree with Comment #33 The simplest solution is to create a default folder for firebird. It's not elegant and I, for one, don't like it, but at least this way we can fix the major dataloss part of it. That way we can get 0.8 released on time and worry about the "proper" fix for this in the 0.9 release.
Ben checked in a patch (turn off "Safe Upgrade", the feature that deletes stuff) in dialogs.c on both the trunk and the branch on 12/17/2003 (5-6 days ago). Two hours ago, he backed out that patch and checked in a similar patch to setup.h and extra.c, but only on the branch. I don't know if his checkin today was because the first one didn't work, or because it was just a better way to do it.
There are a lot of sugestions about how to fix this, but the simple solution is: 1. First check to see if the folder exists and appears to actually have a previous version of firebirrd in it. No MozillaFirebird.exe file present, don't try to delete anything. 2. Assuming there is a MozillaFirebird.exe folder in the target install directory then remove only plain files in the directory, and only the following folders: chrome components defaults plugins res searchplugins uninstall 3. If the directory exists and is non-empty and there is no MozillaFirebird.exe file in it, give a warning pop-up saying "You are installing Mozilla Firbird in a directory containing other applications. This is NOT recommended and can result in loss of files related to other programs during subsequent upgrades of Mozilla Firebird." (unfortunatley this would mean getting the Internationalization people involved to translate this). This way if you accidentlly give it the wrong path it will do limited damage. If you install firebird into a directory with other things and not in it's own subfolder and you don't read what the checkbox for the so-called safe install says it does, I think you deserve what you get. That said, however, I think the wording of what the safe install does, could be clarified a little and the name should be changed from safe install to something else, because as you can see from this bug, what is safe for some is disasterous for others.
I have re-nominated this bug as a 0.8 blocker. At the bare minimum, before the release, we need to change the checkbox for something that has caused this many people to lose data, to NOT include the word "safe" in it. We can change it to "Clean Upgrade". "Remove all files from directory before install". Anything really, just not "Safe Upgrade".
Flags: blocking0.8- → blocking0.8?
just because it isn't a blocker doens't mean it won't get fixed in time, I'm building from CVS to test the checked in fix. That still doesn't make it okay to "re-nominate" this or any other bug. The final decision on whether this is a blocker is ben's, per comment 32. Any further abuse of the flags may result in revocation of Bugzilla permissions. Three times is three too many.
Flags: blocking0.8? → blocking0.8-
Sorry. I did not realize Ben had previously turned the blocker off. The blocker had been turned off, by someone other than Ben, and it was a name I did not recognize.
as a note, as of Ben's checkin last night, this will not happen on branch builds. The problem can still exist with the trunk builds though, as the fix checked in is to turn off the "safe upgrade" codepath by default. (You can still turn it on if it detects an existing install). Better detection of existing files is needed to make this really work as desired, but this is okay for now.
Regarding the tacking of MozillaFirebird onto the entered path. As most people will be used to installing to C:\Program Files\MozillaFirebird it'll cause the location to change from C:\Program Files\MozillaFirebird\MozillaFirebird.exe to C:\Program Files\MozillaFirebird\MozillaFirebird\MozillaFirebird.exe which is daft. Why not take the lead from SeaMonkey and have the default path of C:\Program Files\Mozilla.org\ so we get C:\Program Files\Mozilla.org\MozillaFirebird\ Hope that makes sense. The only other thing I'm worried about is shortcuts pointing to the old build but the installer puts them everywhere so it shouldn't be too much a a problem and most users will delete the 0.7 folder first. Didn't Nero have this problem as well a while ago?
Perhaps we need to change the meaning of "Safe Upgrade"
Related: bug 69153
The installer still nukes the directory from orbit on the branch if you check the "Safe Upgrade" checkbox. I still think this bug should block 0.8, even though you now have to check a checkbox to trigger it.
As a temporary fix for the 0.8 branch only, would it be that hard to just remove the checkbox for "Safe Upgrade"?
As I mentioned before, I think this is a matter of terminology. To Ben, Safe Upgrade means that Firebird will work properly afterwards. To everyone else, it means that it won't harm your hard drive. So people check the box and don't really understand what is going to happen.
For 0.8, I'd be ok with a temporary fix that changes the checkbox label from "Safe Upgrade" to e.g. "Delete contents of C:\Program Files\".
"Delete contents of installation directory" would be a better label, as hard coding a path into the label is not always accurate. If it is installed into D:\Internet, then everything under D:\Internet will be deleted, not everything under C:\Program Files.
Jesse was using C:\Program Files as an example. What he meant was "Delete everything in %INSTALLDIR%?"
Flags: blocking0.8- → blocking0.8+
Flags: blocking0.8+ → blocking0.8-
Flags: blocking0.8- → blocking0.8+
Tom, only the devs are allowed to overrule blocking- or blocking+ flags, or even grant them. In this case, as Ben has already set it to blocking-, and as chief dev of Firebird, no one may overrule him, I'm setting this to blocking-.
Flags: blocking0.8+ → blocking0.8-
Erm, my appologies. I tried to add myself to the cc list, i guess i must have been playing around with the pretty buttons before hand. Sorry again.
Keywords: conversion
Ben checked in the following text changes at 01/14/2004 15:56 -0800 on the trunk (and also on the branch): - Perform a Safe Upgrade + Perform a Clean Install - A Safe Upgrade will completely remove the old installation. ... + A Clean Install will COMPLETELY REMOVE the contents of the install folder! ... Whether that's sufficient to prevent dataloss depends on what users who installed to "C:\Program Files\" were thinking. If they were aware of what they were doing, the new text will help. If they thought they were installing into a subdirectory of "C:\Program Files\", the new text won't help much.
To be honest, I'm not sure that any amount of warning is going to stop someone who doesn't know what they're doing from hosing something important. It's just not standard behaviour for application installers to hose entire directories. Although I know why this is being done, I'm not sure if trusting the user to be intelligent is a safe thing to rely on here. To us its clearly obvious why installing to C:\ or C:\Program Files and then having the installer wipe the directory beforehand is a bad idea. I can GUARANTEE you that there are people for whom this is totally non-obvious and therefore very dangerous.
I think it got lost in the mass of comments here, But I previosuly suggested that a warning window be added if the Install path is a non-empty directory and does not conatain a previous firebird installation. This would help prevent people from accidentally hosing themselves. Something likethe following (with "Back" being the default choice): W A R N I N G The directory you have chosen appears to contain other applications. Installation of Mozilla Firebird in the same directory as other applications is NOT recommended. Doing so could result in subsequent updates of Mozilla Firebird deleting files relating to the other Applications in this directory. Click "Back" to chose another install location. Are you sure you want to proceed? "Back" "Continue Anyway"
Some suggestions in bug 69153 seem like one of the best approaches I've seen or can think of. That bug suggests using an install.log, and using the following behavior: If there is no installer.log the user MUST delete for himself or change dir. If there is an installer.log, delete only the stuff that was installed if there are directories left then HINT the user, that some extensions/plugins can cause problems. I would go one step further and allow the user to manually remove any extensions/plugins from inside the installer itself though.
Re comment #53, the people who have been burned by this are NOT people who don't know what they are doing. Most people who don't know what they are doing will either select the Standard install or leave the default install path (I know not everytone will do this but most people who don't know what they are doing select defaults for installs). The people who got burned by this are people who were used to the way the ZIP builds worked. Rather than extracting to the target folder you specified, they extracted to a MozillaFirebird folder in the path you specified. People got used to this. Those who had files deleted either: a. Thought the installer was going to do the same thing and create a sub-folder for the install in the path they specified. (admittedly this is rather lame behavior for an installer and they should ahve known better) or b. Were just so in the habit of specifying that path as the extract target that they entered it in the installer without really thinking. Re comment #55 I think hey know what the correct fix is but it is not going to make 0.8. That is why I suggested the warning window in comment #54. Seemed to be something that perhaps could be implememnted in time for 0.8 and would at least give you warning that what you were doing is really dumb. But, this is turning into a discussion forum and I am not helping that either.
comment 54 only applies if the user already chose to install to Program Files once, since in the absence of a previous install it doesn't touch the clean install codepath. obviously better determination of what is and isn't appropriate to remove is needed, and will come before 0.9. The method is up to Ben, however he does completely understand the need for the installer to only remove files that could affect a subsequent build.
From burning edge: Fixed on trunk and branch: part of 228672 - "Safe Upgrade" is now called "Clean Install". Also, the description text now includes a stronger warning: "A Clean Install will COMPLETELY REMOVE the contents of the install folder!" Actually using an installer.log is targeted for 0.9, so this sounds like a very reasonable compromise.
I do agree with comment #53. There must be a strong warning about custom path. Let's be honest : only a few user read release notes (see number of invalid / duplicate bug in bugzilla) related to this problem. Well, it looks like there may be a lot of shouting of "strangely minded" people who will install firebird in a wrong location and will be crying because of this :[
Right now the clean install warning is pretty clear. And above it is the path where it will be installed.
Sorry to rant, but this time I'm not sorry for the bugspam. This whole "safe upgrade" or "clean install" or whatever you want to call it should be removed in my opinion. Reason: *No other sensible freeware or commercially available software has this option* Why? It makes no sense to have such an option. All installers I've seen give a warning when they find a folder that is not empty, and that's it. They don't empty that folder. If your freshly installed program doesn't work right after you've installed it, you should have read the warning and choose a blank folder, or let the installer create a new one. If I want to create a folder called Firebird, then create a read-only file called "ssl3.dll" in it, then install Firebird to this folder, and Firebird won't start, I've made a stupid mistake. The installer warned me about that. But I don't have dataloss. Even if the Firebird installer detects that there are only Firebird files in the folder I want to install in, there is absolutely no guarantee that those files (by name) are Firebird files. I would still have dataloss (see example of the ssl3.dll file above) if I used safe upgrade. To all of us (including myself) who regulary install new nightly builds to test them, safe upgrade *might* be usefull. However, a warning indicating that I'm about to install a new nightly in a folder that's not empty *should also ring a bell* to all of us. It is a reminder to us to empty that folder before clicking next, or else we would have a chance of Firebird not running as expected. So, for the sake of any user that wants an installer to behave like it should, remove the safe upgrade option from the installer. Thanks for reading.
Mozilla suite has a serious regression problem that "reminds" of this one. Bug 233014.
How about we dump the current installer on Windows and use the Nullsoft one instead (it's much, much, much better). http://nsis.sourceforge.net/home/
Bug 231062 : Use MSI for installer.
I was just bit by this one, Firefox 0.8, Win2k SP4. Comment # 56 is on target. I am not computer-unknowledgable by a long shot, but I accidentally installed into d:\Program Files. Why? Because I typed in the path I wanted, and the installer did not display the last step of the path - so I assumed that it would add MozillaFirebird. Then I did not notice any opportunity to review the final destination path and change it before the install executed. All other installers I have ever used only delete files that they installed. If a directory is not empty, it will not be removed. If the Firefox installer behaved like this, there would never be a problem. To completely clean a directory may be useful for a developer who installs nightly builds, but the target user is not that developer. The normal user will expect an installer that looks like other installers to act like other installers as well. And there has to be a safe way to recover from mistakes - my installing into d:\program files was a mistake that was helped by the design of the installer, and it is reasonable to expect the installer to reverse what it had dine - and no more! And just in case, please have a non-installer version available, too!
Maybe I'm seeing something others aren't but I did a test of this in a VMware box. 1. Installed to "C:\Program Files\" specifically to test this. 2. I then went to Start > Settings > Control Panel and opened the Add/Remove Apps panel. 3. I selected Firefox to be uninstalled, and after telling it Yes I wanted to remove Firefox, it deleted the installed files, but then presented me with this dialog pictured in the screencap that I have attached. This dialog states: "Attention (!) Not all files were uninstalled from teh Uninstallation directory: C:\Program Files Do you want to completely delete this directory? [ YES ] [ NO ]" If this is the default behavior, then it's merely less-then-optimal design, which helps users make a _bad_ decision without thinking. But, again, if this is the default behavior, it's not as though the user wasn't warned...
Attached image Uninstaller screencap —
As for not getting an option to review the install path, I followed your steps (using C: instead of D:) 1) Choose Custom Install 2) See a screen stating "Firefox will be installed to the following directory: C:\Program Files\Mozilla Firefox" 3) Click Browse, choose C:\Program Files, then OK 4) The screen states "Firefox will be installed to the following directory: C:\Program Files\" This is your first indication of where it will be installed. 5) Click Next, choose components as desired, click Next again 6) See a screen that shows where Firefox is to be installed, along with the components that will be installed. The path shown is once again C:\Program Files. Click Next to continue the installation from there. Based on this, you ignored the stated path twice, making an assumption not borne out by experience with any other installer. If you didn't notice any opportunity to verify the information, its because you didn't pay attention when it was there. Maybe we need to idiot-proof the uninstaller a little more, but the target audience for said idiot-proofing is those people who choose a custom install, then do something silly during the install, then do something even sillier during the uninstall.
Don't have any means of testing myself, but according to a forum thread, when running on Win98 (I guess not SE), the installer doesn't show a button for creating a new folder. AFAICS, that means you can only install to an existing folder with the custom install, which is broken. And, for the record, the folder selection is not the same as in Seamonkey's installer. Seamonkey's installer has a drive/folder select that shows the full path and allows you to edit the name in a text box. Firebird's installer shows only the folder name, and if you type into the box and hit OK, your typing is ignored. Winzip, as another example, uses the same standard folder select as Firebird's installer, but then adds \Winzip on to the end of the selected folder, and lets the user edit the pathname in a text box. The nullsoft installer and the apps that use it do the same thing - the user selects a folder, clicks ok, and the installer adds \appname on the end and then lets the user edit the path. Firebird's installer doesn't give the user an edit box with the path in, instead the user is expected to create the folder in the folder select dialog. In the case of Win98, Firebird apparently doesn't give the user a way of creating the folder. People's assumption that Firebird is going to add the path on is based on the behaviour of other installers. It's true that Seamonkey's installer has related problems. It's also true that people are making assumptions based on other, different, installers. Neither of those is a reason not to improve this.
Please do NOT morph this bug to cover the UNinstaller! This bug is about the installer itself trying to be helpful by getting unknown junk out of the way (e.g. old components that will crash on startup due to interface changes). The UN-installer feature mentioned in recent comments was added for a different reason--people complained that uninstalling did not remove extra extension junk--and needs to be addressed in a different bug.
I can't believe that we are arguing about whether this is acceptable or not. An installer that deletes every program on your computer, with no way to recover, should not be released. It doesn't matter what settings you have to click to get there, somebody will do it, as shown already by several people in addition to the original moron, moi. I am confident that this will be fixed properly. Jesus, I think you may have misunderstood the original problem. The installer itself will delete the entire installation folder, and this installation folder may be set to Program Files, or even the root drive, by using the custom install. Uninstallation problems are a different bug. Michael, than you for reminding people that under Win98 there was no button to create a new Firebird folder. This is why I assumed that the installer would do it instead of blowing away the base folder.
Ian, this functionality is currently disabled by default, and you can't enable it since it skips the screen in question. Once we have better checking for appropriate files, the clean upgrade approach will be reinstated. The only way under the 0.8 installer that you can remove all of Program Files (or any other folder) is to click yes to the dialog in the screenshot.
In reply to comment 72: Mike, What you're describing has nothing to do with this bug. Your statement "The only way...that you can remove all of Program Files...is to click yes to the dialog in the screenshot" is incorrect. The problem being discussed in this bug is the INSTALLER deleting files, *not* the uninstaller. Can we please keep the discussion on track. The problem, as has been discussed previously, is that the Installer (*not* the uninstaller) deletes everything in the target directory before installing files there. For some background discussion on this issue, please see my posts on MozillaZine and the other posts on the topic: http://www.mozillazine.org/talkback.html?article=4252#22 That post also has some suggestions regarding how to rectify this problem. I am not trying to be a jerk but people are really taking this discussion off-topic and confusing the issue.
Re: comment 73 -- have you tried the actual 0.8 release? As claimed in comment 72 Ben turned off this feature of the installer as an interim stop-gap. http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/browser/installer/windows/config.it The -UN-installer can still lead to similar disastrous results, but the fix is elsewhere and should be dealt with in a different bug (dunno if one already exists or not). This bug is still open (I assume) so the install upgrade mechanism can be fixed correctly and turned back on.
Dan, Thanks for the explanation, I totally missed that happening. I saw the behavior I described just a couple days before the 0.8 release so I didn't realize that it was disabled already. In that case, I'll shut up now, apologies for my previous comment. And thanks to the developers for disabling the delete feature in the installer until the issues can be fully worked out. Regards
The uninstaller bug is bug 233625.
Comment 61 is right, This whole "safe upgrade" or "clean install" or whatever you want to call it should be removed. It's easyer to delete an installation that don't work properly, than to try to undelete a whole directory erase by an installer. Keep in mind, that's not all user that are experience user and most of then don't read the warning before installation and if they install in C:\Program Files and after the installation every thing on C:\Program Files is deleted, you can be sure that Firebird will have bad press. Don't forget, an installer should install, not delete directory wether the user was warned or not.
Enough already. This is bugzilla. This is NOT the firefox Bugs forum. Comments here are supposed to be to help developers resolve issues.
*** Bug 233625 has been marked as a duplicate of this bug. ***
I don't know if this has been said already, and I don't intend on reading through 70+ comments to find out, but one way to easily resolve this might be to have the install create a folder in the install directory to install to (much easier to understand through example). eg. The install directory is set to "C:\Program Files" The installer creates the folder "Mozilla Firefox" inside "C:\Program Files", so Firefox.exe ends up being in "C:\Program Files\Mozilla Firefox". If the install directory is set to "C:\Program Files\Mozilla Firefox", then the Firefox.exe ends up being in "C:\Program Files\Mozilla Firefox\Mozilla Firefox". Redundant? Yes. But it fixes the problem very quickly and easily, as the Firefox files will never simply be scattered in C:\Program Files
Next time, please read the 80 comments.
Priority: -- → P2
Target Milestone: Firefox0.9 → Firefox1.0beta
the installer no longer deletes unrelated files. it just installs over the top.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 242118 has been marked as a duplicate of this bug. ***
i think it has to do with win98
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: