Closed Bug 200651 Opened 22 years ago Closed 21 years ago

Add warning about possible mozilla instability when destination folder is not empty

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 210731

People

(Reporter: matp75zilla, Assigned: ssu0262)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401

This RFE is about checking is the destination folder is not empty and warn the
user that this could be a source of problems.
Please note that is possible to run the desinstaller and still have an non empty
directory because it is not possible to desinstall everything cleanly with the
uninstaller.(like calendar...)

Please see bug 195600 comment 6 (and bug 200623) for problems appearing after
non empty destination directory.
interesting related bug are also bug 7884 and bug 19713 

Reproducible: Always

Steps to Reproduce:
reporter,  would this be Windows only?  Linux currently does warn user that
directory contains files (no upgrade process exists-see bug 69153) 
confirming enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 200419 has been marked as a duplicate of this bug. ***
*** Bug 209309 has been marked as a duplicate of this bug. ***
*** Bug 209623 has been marked as a duplicate of this bug. ***
*** Bug 209788 has been marked as a duplicate of this bug. ***
*** Bug 208205 has been marked as a duplicate of this bug. ***
The result of installing mozilla into a non-empty directory usually is a
non-working Mozilla.

-> Critical
Severity: enhancement → critical
Summary: [RFE] Add warning about possible mozilla instability when destination folder is not empty → Add warning about possible mozilla instability when destination folder is not empty
*** Bug 209800 has been marked as a duplicate of this bug. ***
*** Bug 209794 has been marked as a duplicate of this bug. ***
*** Bug 209839 has been marked as a duplicate of this bug. ***
*** Bug 209830 has been marked as a duplicate of this bug. ***
All duped crash bugs actually are a dupe of bug 195600. The cause is described
in one of its dupes: bug 200623 comment 4.

Also note that this is SPAWNED by bug 195600 comment 15 and that this bug deals
with AVOIDING future dupes of bug 195600.

I recommend to dupe new "failed installation" bugs against bug 195600 and if
people reading that bug find this one interesting they can CC themselves to this
bug.


*** Bug 209936 has been marked as a duplicate of this bug. ***
Oops, sorry about the mass duping to the wrong bug, Patrick.  I guess bug 195600
was off my radar since it was marked invalid.

Anyway, the Linux and Mac installers will *refuse* to install Mozilla into a
directory that currently has mozilla installed.    The Windows installer will
gladly install over top of an existing installation.    I consider this a bug,
rather than a RFE, so that's why I changed this bug's status.   (Was I wrong to
do that?)

The other thing to consider is that there may be two issues at hand.  One is if
the user is installing over top of an existing installation, and the other is if
the user actually did uninstall first, but some add-ins or other things were
left behind.      Should those be two separate bugs?

FWIW, the linux Mozilla installer checks for a file called "mozilla-bin" and if
it finds that, the installer will not proceed before deleting the directory. 
(Mac checks for "Mozilla")
[sorry all readers for the spam, i considered a PM to WD]

WD: my reason for separating bug 195600 and this one is that when people get a
crash when they upgrade:

1) The RESOLUTION for that crash -> read the installation notes ;) and clear out
the Moz dir. This = bug 195600 

2) AVOIDING such installs can be done in several ways:
- _warning_ the user about non-empty dirs. This = bug 200651 [this one]
or
- _check_ for empty dir [with things like bug 69153 as possible side-effect]. 
or
- _build_ XPI uninstallers = bug 7884.

My reasons for marking bug 195600 "invalid" is that so-called upgrade installs
go against the installation notes AND that the crash isn't caused by Mozilla
itself but by third party add-ons.

Speaking for myself: i think there are many dangers related to just wiping a
folder contents before installing, so i don't think that's the way to go. XPI
uninstallers would be neat, but i don't think that people actually realize that
that can be the cause after they already did an uninstall of Mozilla. 
That leaves "installation notes" or a "warning during install".

Whether this is an RFE or bug: for an end-user product i'd say "bug". If Moz is
for development purposes only, i would say RFE. 
Requesting a blocker flag for 1.4 even though I am aware that there is no fix
for this yet.

This bug deals with avoiding a highly-visible crash bug for upgraders once 1.4
is released.

I know it's in the installation notes, but the dupes show that that is not enough.
Flags: blocking1.4?
*** Bug 209975 has been marked as a duplicate of this bug. ***
*** Bug 209838 has been marked as a duplicate of this bug. ***
Read the slashdot thread on RC3.  This should be a blocker.  If not, it will be
an embarassment.
bug 210731 will take care of this.
*** Bug 211383 has been marked as a duplicate of this bug. ***
Blocks: 195600
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?
Given the landing of bug 210731, should this bug be marked VERIFIED FIXED?
They're essentially dupes at this point.
I see absolutely no reason why this shouldn't be a dupe of 210731, so I'm
marking it as such. I realize this bug has the lower number, but 210731 is
patched and marked fixed, so this is the dupe by default. If I misunderstand
things and this is not a dupe, please reopen.

*** This bug has been marked as a duplicate of 210731 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
No longer blocks: 195600
mcaplan@telusplanet.net: please don't remove bug dependencies w/o any comment.

First off: in the normal bug view it's impossible to see that a dependency has
been added or removed [and by whom] or if it ever existed.

And secondly: people might want to know why a bug suddenly doesn't depend on
another bug anymore.
Thanks! :)
Product: Browser → Seamonkey
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.