Closed Bug 228672 Opened 21 years ago Closed 20 years ago

Installer deleted unrelated folders

Categories

(Firefox :: Installer, defect, P2)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED
Firefox1.0beta

People

(Reporter: mozilla, Assigned: bugs)

References

()

Details

(Keywords: conversion, dataloss, relnote)

Attachments

(1 file)

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.
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: 20 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.