69153 - [LINUX]Warn users about the directory we're going to wipe out before we do it (e.g. /usr or /usr/bin)

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[John-Paul Stanford]

I was upgrade from mozzila milestone 0.7  to milestone 0.8. The 0.7 version was 
installed in /usr ( /usr/lib/mozilla and /usr/bin/mozilla ) 

When installing the 0.8 release with the full installer it asked if I wanted to 
remove the old version. I said yes to this. It seemed to take a while stoped it 
by reseting (could not get the system to respond anyother way). When linux 
booted back up I discoverd that every file and director under /usr had been 
deleted makeing my system useless.

Comment 1

[Sean Su]

reassigning to sgehani

Comment 2

[Samir Gehani]

The coarse-grained upgrade strategy is sub-optimal.  John-Paul, did you have a
directory or file named /usr/mozilla and then chose "/usr" as the detsination
directory to install to?

We need to change this to upgrade the surgical upgrade strategy the windows
installer has adopted.

Comment 3

[Samir Gehani]

*** Bug 76748 has been marked as a duplicate of this bug. ***

Comment 4

[Boris Zbarsky [:bzbarsky]]

*** Bug 82872 has been marked as a duplicate of this bug. ***

Comment 5

[Bradley Baetz (:bbaetz)]

*** Bug 84701 has been marked as a duplicate of this bug. ***

Comment 6

[Michael Hendy (Hendikins)]

*** Bug 90327 has been marked as a duplicate of this bug. ***

Comment 7

[basic]

adding (install deletes /usr or /usr/bin files) to summary so that it turns up
on more searches

Comment 8

[R.K.Aa.]

this is a baddie. Is there a release note? (If not please add at least relnote
keyword)

Comment 9

[R.K.Aa.]

*** Bug 97318 has been marked as a duplicate of this bug. ***

Comment 10

[Grace Bush]

reassign

Comment 11

[Grace Bush]

*** Bug 92462 has been marked as a duplicate of this bug. ***

Comment 12

[Curt Patrick (gone)]

I think this is of interest to nsenterprise.

Comment 13

[Curt Patrick (gone)]

*** Bug 102177 has been marked as a duplicate of this bug. ***

Comment 14

[Samir Gehani]

Link to doc added.  

Comment 15

[Michael Hendy (Hendikins)]

*** Bug 113248 has been marked as a duplicate of this bug. ***

Comment 16

[Andreas Franke (gone)]

The description of "critical" mentions dataloss bugs. Deleting the user's
operation system is extreme dataloss; it's hard to think of a worse one.
Since this has happened to several people already, I'm changing the severity
from "major" to "critical", and adding "relnote" and "mozilla1.0" keywords.

CC'ing blizzard because bug 84701 and bug 82872 mention that Redhat 7.x installs
mozilla in /usr/bin, finally leading to the desaster of an unusable machine.

Comment 17

[Daniel Veditz [:dveditz]]

*** Bug 120389 has been marked as a duplicate of this bug. ***

Comment 18

[Syd Logan]

assigning to me

Comment 19

[Syd Logan]

Not sure how this missed the nsbeta1 nomination list. 

Comment 20

[Syd Logan]

taking

Comment 21

[Syd Logan]

minusing, won't do for MachV

Comment 22

[Daniel Veditz [:dveditz]]

*** Bug 125440 has been marked as a duplicate of this bug. ***

Comment 23

[Grace Bush]

*** Bug 125985 has been marked as a duplicate of this bug. ***

Comment 24

[R.K.Aa.]

*** Bug 130561 has been marked as a duplicate of this bug. ***

Comment 25

[jlarsen]

I don't know if this should be a second bug, but in all systems if installer
fails (which is very possibly on a network installer). The entire mozilla
directory is wiped. Meaning you loose your use of mozilla completly till you can
get an installer to work. Which could be a while if the network installer failed
because of traffic to mozilla.org meaning you might have to use IE in the
meantime! GASP  HAHA

Comment 26

[Paul Arthur]

I experienced this problem with RC2.  I have Red Hat 7.2 which had the following
older mozilla packages installed:
mozilla-0.9.2.1-2
mozilla-psm-0.9.2.1-2
mozilla-mail-0.9.2.1-2
These were installed in /usr/bin.  I attempted to install over it answering
'Yes' to delete the older mozilla files.  It deleted everything in /usr/bin.

Comment 27

[Christopher Blizzard (:blizzard)]

Wow, are you serious?

Comment 28

[John Levon]

blizzard, I thought that's what this bug was all about ??

I've seen it with $HOME/bin/ but thankfully wasn't installing
in /usr/bin

Comment 29

[Dom Lachowicz]

blizzard - it honestly wiped my /usr/lib

Comment 30

[Grace Bush]

*** Bug 144888 has been marked as a duplicate of this bug. ***

Comment 31

[Grace Bush]

*** Bug 145038 has been marked as a duplicate of this bug. ***

Comment 32

[leif sawyer]

It's true.  It wiped out most of my /usr.  I mount my local users at
/usr/local/home, and that would have been disastrous if I hadn't killed the
installer.  How did i find out? I was playing MP3s out of /usr/bohemia, which is
a local artists mp3 stream.  That died pretty quickly, and upon investigation,
the whole directory had been wiped.  2+2= installer bug, and I killed that
sucker before any more damage could be done.

I had been meaning to rebuild the system and restore personal data anyway, but
this sort of made it imperitive.

Comment 33

[Nicolás Lichtmaier]

Attachment: Simple fix v1.0

I've added a simple check to avoid destroying filesystem. If the directory has
mozilla-bin but it doesn't have a chrome directory, then it doesn't seem to be
an old mozilla instdir and the directory is rejected.

Comment 34

[Randell Jesup [:jesup] (needinfo me)]

targetting for 1.01; drivers would like this fixed in that timeframe

Comment 35

[Nicolás Lichtmaier]

Attachment: Fix v1.1

I just use ConstructPath instead of manually edith the previous value of
"path".
Now I check that chrome is a directory. I've replaced sprintf for snprintf.

Comment 36

[Daniel Veditz [:dveditz]]

*** Bug 146812 has been marked as a duplicate of this bug. ***

Comment 37

[André Dahlqvist]

> I've added a simple check to avoid destroying filesystem. If the directory has
> mozilla-bin but it doesn't have a chrome directory, then it doesn't seem to be
> an old mozilla instdir and the directory is rejected.

I'm probably misunderstanding you, because from this description I don't see how
this can help. If a user has installed mozilla to the root of /usr, then there
will also be a chrome directory directly under /usr. What am I missing?

Comment 38

[Nicolás Lichtmaier]

This will fix the problem of users installing to /usr/bin. Users who had
installed a Linux distribution version of Mozilla and have a mozilla-bin there.
They tell the installer "hey, I want my mozilla in /usr/bin", mozilla-installers
checks that there's a /usr/bin/mozilla-bin file and deletes the whole directory.

You are talking about a user who has previously done a broken install into /usr.
This guy will have a /usr/mozilla-bin binary. *Such an install should have never
been allowed in the first place*

Perhaps a check for explicitly avoid any install to "/usr" or "/usr/local" alone
should be hardcoded too. Or I could check for directories that are often placed
in "/usr" or "/usr/local", like "share".

Comment 39

[leif sawyer]

I'm confused -- 
Why wouldn't the installer manifest what files it put where, and just
reverse the order on the way out?

If it had to make directories, it could remove them.  Otherwise it should just
leave it alone and alert the user that 'some files still exist -- manual cleanup
may be necessary'

Comment 40

[Daniel Veditz [:dveditz]]

Why no uninstaller? because the unix installer was always a side-project done
for love and never fully invested in. Lots of linux people prefer RPM's so there
are few volunteers to clean it up, and Netscape doesn't want to spend the money
because most linux people who know enough to be unhappy with the one we've got
seem to prefer Mozilla.

The install logs are there. That's what the windows uninstaller uses. Someone
just needs to write an uninstaller to process it and then make the install
script call that instead of deleting the entire directory.

(This is taking this bug in a different direction that when originally written.
when written we envisioned stopping the deletes and instead forcing upgrades of
existing components to prevent mismatches. This is what the windows installer does.)

Comment 41

[Nicolás Lichtmaier]

This bug report was about a specific incident causing dataloss. There are might
many ways to avoid it, but something should be done. Because of waiting for the
ideal solution, people kept loosing their files. IMO the "surgical upgrade"
should have been proposed in another bug. I could have tried to implement the
ideal solution, but it's available only to Netscape employees.

Comment 42

[Daniel Veditz [:dveditz]]

> but it's available only to Netscape employees.

What?

Comment 43

[Nicolás Lichtmaier]

Well... what does "http://puma/xpinstall/UpgradeOptions.html" mean then?

Comment 44

[Daniel Veditz [:dveditz]]

Oh, *that* "it"; you weren't very clear. The puma document is an obsolete spec,
completely unnecessary to the discussion. A better place to start would be the
different FORCE_UPGRADE feature implemented in the windows installer. See
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/windows/config.it#463

This is combined with deletion of specific obsolete files in the install
scripts, which the unix install scripts already do:
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/unix/browser.jst

I don't want to stop the current patch, just don't want that to close this bug
because it doesn't solve the whole problem (see comment 37. Simply blocking /usr
and /usr/local installs would only move the bug along to some other vulnerable
directory stupid users could pick).

Comment 45

[Nicolás Lichtmaier]

Attachment: And now: v1.2

I've added a check for "share". Rationale: a "share" directory is normally
created by unix software installations. So we'll catch with this any "path
prefix" which was used to install UNIX software.
I've also fixed some code for wrapping strings...
IMO this should be reviewed and checked in. Do it or else... I'll keep posting
patches =).

Comment 46

[Nicolás Lichtmaier]

I've read about "force upgrade".. yes.. it should be done. But something simple
that can be done for 1.0.1 is just save the selection to a file
installer-selection. Then when installing, if that file exists, it can be read
before removing the old mozilla directory.. :)

Comment 47

[Nicolás Lichtmaier]

Please, could someone review this?

Comment 48

[Adrian Ulrich]

*** Bug 148834 has been marked as a duplicate of this bug. ***

Comment 49

[Syd Logan]

Some comments on the patch. First, we should be reading mozilla-bin from
somewhere, not hardcoding it. The installer is supposed to be vendor neutral.
For Netscape for example, the binary name is netscape-bin, not mozilla-bin.

Second, I don't see what this fixes really (which means the first issue is
irrelevant). The key to the fix is we need to ensure is that we only remove
files that we had installed previously. The patch breaks down if the user is
upgrade installing an install that was made to /usr, as pointed out in one of
the comments: 

"You are talking about a user who has previously done a broken install into /usr.
This guy will have a /usr/mozilla-bin binary. *Such an install should have never
been allowed in the first place*". 

Well, we have to consider this case. How can it be done? One way would be to
force the installer to only allow clobbers of directories that we have created.
If the user had installed into an existing directory, then we either disallow
upgrades there, or we warn them strongly that what they are about to do will
tube any and all files. How can we know that the install directory was created
by us in a previous install? We could simply create a marker file in the code
that creates a directory in response to the user selecting a directory that does
not exist (The directory you are installing to does not exist, would you like to
create it?. Even better, the marker file would contain an ls(1) of the contents
of the directory after the install (plus any files we know are created by the
browser for this version, the marker file could be constructed by the build team
and included in the browser.jst file). When we come back and install, if the
directory exists, and it does not have the marker file, then we better warn the
user since it might have been something like /usr. If the marker file is there,
and the contents don't match an ls of the directory, we should warn the user as
well (because the directory may contain something that was not installed by us
that they do not want deleted, a message like "The directory appears to contain
files that were not a part of the previous install of [Mozilla/Netscape]. We
suggest you make a backup of the directory before installing here, or choose
another directory".

Comment 50

[Syd Logan]

additional comments from an IRC log:

<nick> we allow empty dirs
<syd> good point
<nick> in fact, I did something like that
<nick> and later removed the code
<syd> we could check for empty dirs and treat that similar to our creating it,
and write the marker file

Comment 51

[Nicolás Lichtmaier]

Well... this is what I popose:

Mozilla can be installed in 3 types of directory:
1) non-existant
2) empty
3) mozilla only directory, marked with a marker file.

If the directory hasn't got the marker file, it exists, and it has already other
files ther will no way to install Mozilla there.
When installing Mozilla will create the marker file at the start of the process,
so that to allow reinstalling if the installer crashes. Leaving the marker file
the installer is saying "I know I've created this directory, or I found it
empty, so you can delete this in the future because it's just Mozilla".

One unresolved problem: How do we implement this for the first time? Should we
rush to add at least the marker file creation to 1.0?

Comment 52

[[e-mail]]

Why not use one of the already existing files as the marker file,
e.g. file "mozilla"? This file could just be "touched" to create
an empty file at the beginning of the installation and will then be
overwritten with the true fiel later in the installation process.

Comment 53

[R.K.Aa.]

*** Bug 154593 has been marked as a duplicate of this bug. ***

Comment 54

[Matthias Versen [:Matti]]

*** Bug 155208 has been marked as a duplicate of this bug. ***

Comment 55

[Andrew Schultz]

*** Bug 159678 has been marked as a duplicate of this bug. ***

Comment 56

[Andrew Schultz]

*** Bug 160708 has been marked as a duplicate of this bug. ***

Comment 57

[guenter]

At least you should change the README file, so that "upgraders" do not
expand(like me) the latest version installer into a subdirectory of the existing
mozilla dir.
Because the installer deletes ALL, including the new install dir:-(

Comment 58

[guenter]

At least you should change the README file, so that "upgraders" do not
expand(like me) the latest version installer into a subdirectory of the existing
mozilla dir.
Because the installer deletes ALL, including the new install dir:-(

Comment 59

[Nicolás Lichtmaier]

Uhm... what I've proposed in comment #51 has one big problem. Users of previous
mozilla versions: without the marker file won't be able to upgrade the browser.
They would need to manually remove the directory.

I'd like to remark that the current proposed patch would have saved all this
users deleting their files! I propose this to be checked, and then wee what else
can be done...

Comment 60

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 61

[Patrick]

*** Bug 176478 has been marked as a duplicate of this bug. ***

Comment 62

[Patrick]

I am a bit confused here (agreeing with comment 16) : Moz installer eradicates
entire /usr or /usr bin folders and this is only listed as an ENHANCEMENT?!

Also the target milestone needs updating.

Comment 63

[Elmar Ludwig]

This is not an enhancement -> restoring severity to critical.

Comment 64

[R.K.Aa.]

*** Bug 183938 has been marked as a duplicate of this bug. ***

Comment 65

[Patrick]

Comment 64 : not only the plugins disappear (which can be partially be
circumvented by putting them in the profile folder) but also any other apps/xpi
that were installed (such as mozdev projects like Calendar, MozTweak etc.). And
as far as i know these files can NOT be installed in the profile folder. Which
means that with every new build that a user installs all other projects need to
be reinstalled, with all the necessary restarts of Mozilla. Since i know of no
workaround for this, this is really a major nuissance!

Granted, small nuissance compared to having to reinstall your entire Linux box
;) but i only wanted to point out that even if a proper Mozilla directory is
chosen, the installation procedure needs updating.

Comment 66

[Warren Postma]

This happened to me also.   

Minimal bug workaround solution:

(1) If user enters a with other non-mozilla files in the +x attribute set, the
installer ought not to remove the directory if there are other executables in
that directory.  

(2) -Or- Only chrome directories should be removed. 

Warren Postma, Toronto
[e-mail]

Comment 67

[Jo Hermans]

*** Bug 197371 has been marked as a duplicate of this bug. ***

Comment 68

[Andrew Schultz]

*** Bug 202502 has been marked as a duplicate of this bug. ***

Comment 69

[Ayan mahalanobis]

Come on guys this is big. I refuse to use mozilla henceforth unless they can
provide us with rpm's. It is highly, morally irresponsible to screw up some ones
computer and they won't fix it. What does a upgrade mean?
AYan

Comment 70

[Andrew Schultz]

> I refuse to use mozilla henceforth unless they can provide us with rpm's.

Well, ok, if you insist.
http://download.mozilla.org/pub/mozilla/releases/mozilla1.3/Red_Hat_8x_RPMS/
http://download.mozilla.org/pub/mozilla/nightly/2003-06-17-11-1.4/

Comment 71

[Andrew Schultz]

*** Bug 209677 has been marked as a duplicate of this bug. ***

Comment 72

[Andrew Schultz]

> http://download.mozilla.org/pub/mozilla/nightly/2003-06-17-11-1.4/

should have been
http://download.mozilla.org/pub/mozilla/nightly/experimental/gtk2/1.4rc1/

Comment 73

[Grace Bush]

*** Bug 210969 has been marked as a duplicate of this bug. ***

Comment 74

[beanladen]

Ehm, I just stumbled over this bug by accident. If it is still the case that the
installer can delete the whole system, END USERS ACCESS TO MOZILLA MUST BE 
IMMEDIATELY STOPPED ! Guys, this can lead to really EXPENSIVE claims for damages
in most countries ! Esp. since this is a known deficiency for MORE THAN ONE 
YEAR and there is ABSOLUTELY NO REMARK in the release notes ! Are all developers
have gone mad ???

Comment 75

[timeless]

http://www.mozilla.org/binaries.html                  mozilla.org Binaries

We make binary versions of Mozilla available for testing purposes only.
We write code and post the results right away so people like you can join our 
testing process, try it out, and report the bugs you find.

It's guaranteed that you'll find bugs. Lots of them.

Mozilla might crash on startup.

It might delete all your files and cause your computer to burst into flames. 
Don't bother downloading Mozilla if you're unwilling to put up with problems.

Comment 76

[Daniel Mota Leite]

Ok, but at least a warning in the README/Release Notes is more than needed...
we are talking about people getting they system trashed !!!

imagine someone updating the mozilla to show the computer owner the new features, they would not be happy by losing their system, the guy that tried to help would be in a very bad situation and both would thing twice before recommending to others the mozilla..

at least with a warning, most of the people will read it before updating and save their system

Comment 77

[Frederic Bezies]

*** Bug 211601 has been marked as a duplicate of this bug. ***

Comment 78

[Jeff Echtenkamp]

Agreed with alot of the above comments.  I just (tried) to install Mozilla 1.4
on my Redhat 9.0 machine, and it trashed my /usr/bin.  Needless, to say I was
ticked.  When I checked bugzilla and saw this bug has been reported over 2 and a
half years ago, I'm now furious, to the point I'm ready to ask if anyone has any
recommendations for a different browser... as my form of protest.  While its
hard for me to understand how a bug this severe could go on for so long, its
even harder for me to understand how requests for a documentation note in the
install section go unheard, or even maybe some simple check like counting how
many files you are going to nuke before you do it, or like many programs before
you nuke the entire contents of a directory, pop up a dialog box saying exactly
what you are doing and making me click "yes".

I'm a big linux/open source advocate, and this is embarassing.  I now have to
explain to my boss (who uses a PC, but let me put Linux on mine after a little
pursuading) why I have to spend half a day reinstalling the OS on my machine
because upgrading my web browser trashed my system.  I'm near the end of a
project right now, and don't have time for this.  Hopefully he'll be
understanding enough to let my reinstall be of Linux, and not make me give my
machine to our IT department to put their standard Windoze install on it.

Comment 79

[Nicholas Allen]

*** Bug 226370 has been marked as a duplicate of this bug. ***

Comment 80

[Phillip]

It seems like there's a REALLY simple thing that could alleviate most of this
problem.  Instead of saying "I found an old version of Mozilla in this
directory.   Shall I delete it?", replace that with "I found an old version of
Mozilla in this directory.  To install a new version here, I need to remove ALL
files (or all executable files, or whatever is appropriate) from this directory
and any subdirectories.  Shall I delete these?"

Most users who know that the old Mozilla is in /usr/bin (thanks to the RedHat
install) would also know enough to realize that deleting all executables in
/usr/bin is a REALLY BAD idea.  The warning only tells about removing Mozilla
though, and this disastrous message has apparently caused MANY people to lose
their entire operating system (including ME... GRRRR!!!!!)

IF no message is included in the release notes, and nothing is done to prevent
wiping non-mozilla files from the install, at least warn people that this will
happen.  I suspect that this will limit the bulk of the damage.

Phillip

Comment 81

[beanladen]

No. The path to proceed here in a clean way is
1. Don't allow any installation of mozilla as it has been done 
   by Redhat. ALWAYS append 'mozilla/' to a directory selected.
   The installation tool should CLEARLY state into what
   directory the binaries will finally be copied. There
   should be no way to misunderstand that selection.
   There are a lot of software packages which demonstrate how a good
   installation tool should look and work (indeed, almost all except
   Mozilla...).
2. Deletion of broken installations must be interactive.
   The tool must detect where and if the binaries and plugins
   are installed in a directory not ending with the default
   extension 'mozilla/' (I think that's not too difficult...).
   In that case, the user must be prompted with a modifiable
   list of files to be deleted. Since that list will be long
   the way the tool works now, we come to point ....
3. The list of files to be deleted should be generated from
   a file with a list of files and directories of mozilla, which  
   should ideally be delivered already with any version, so
   that a new version gets the list from the older version.
   That file list could be generated by the installer itself
   for any version it installs (it only needs the top level
   files and directories, except plugins).
   The contents of the plugins and extension directories are 
   either completely listed in that file, or they are not in
   that file, so they will not be deleted. Either case is safe.
   Possible incompatible plugins cannot be removed in a safe
   way by a simple installer tool, another solution is needed
   here.
4. For those who must upgrade from a /usr/bin installation
   or any other installation for which a filelist file cannot
   be found, 3. should be used from the new version filelist to
   get a tentative list of files to be deleted, but the user must
   confirm and modify that either way. Those installations are really 
   broken and cannot be cleaned in any automatic AND safe way.
5. For installations with the 'mozilla/' extensions, automatic deletion
   without interaction is safe with 3. .

Comment 82

[Phillip]

I'm actually just trying to indicate a QUICK and SIMPLE fix to implement until
the proper fix can be created.  Even just the warning that ALL files from the
target directory will be deleted would have been sufficient warning to stop me
from making the mistake I made.  Providing a message telling me that it was
removing just my Mozilla gives the WRONG message.

If someone is willing to fix this properly for the next release, great.  If not,
though, I'd REALLY appreciate at least having the wording of the removal prompt
modified to indicate what it's REALLY about to do.

Either way, it's inexcusable to me to have this bug hanging around in the 1.5
version when the problem was reported in February, 2001 (in the release 0.7 days!)

PLEASE do something to keep this from destoying still more systems in the
future!!!!!!!!!

Comment 83

[Timothy M. Crider]

Hey guys,

 I was the one who submitted this bug 2.5 years ago, and I thought I would 
give you a little background as to how the system got the way it was. This was 
the first time I had ever tried to use a GUI on Linux, and when installing the 
browser it asked for a path to install. I had assumed, that the mozilla 
directory was going to be created under the directory I chose. I know it was a 
stupid mistake, but not one that's all that uncommon. If the installer would 
have come up with something that said.

You are installing to the following:
Binaries:
/usr/bin/
Libraries
/usr/lib

etc...
I would have seen that it was not going to create the mozilla directory and 
gone back and fixed it there.

Also, how difficult would it be to add into the uninstaller a step before 
actual removal that says something like.

Issuing the following commands:
rm -rf /usr
rm -rf /etc/mozilla

since that seems to be what the uninstaller actually does. That would have 
also raised a flag that this was going to do something very bad.

I know 'newbieness' is not an excuse for blowing up a system, but now that 
Linux is starting to get more attention as a desktop it will probably happen 
more often. I hope this helps clear up how the mistake was made and hopefully 
provide some insight on how to correct it.

Tim

Comment 84

[Ron Cooper]

I find it funny this is still not fixed after all this time. 
It is really not that difficult of an issue. If you know what files 
are going to be installed and you save that information, then you should be 
able to easily remove the same files. We assume the packager knows what files 
are included.  You should be able to verify the exact same files by calculating 
a CRC or a simple checksum of each one. You ignore the cases where there are 
missing files, and for those files that don't match you simply make a 
recomendation to the user and let him decide what to do.   What is so hard 
about that? 
 
I submitted bash code that did this over a year and a half ago to the Mozilla 
folks and it was completely ignored. So here we are today and the problem still 
exists. Irresponsible is the only word for it. 
 
Yes, I am  very annoyed. A simple problem that doesn't take a lot of effort to 
fix, but someone has to be bothered enough to try to fix it.  I have not looked 
at the current code, and so I have no idea how it intends to work or not work.  
 
Last, please do not aspire to enforce some kind of lame constraints on the end 
user by not allowing Mozilla to be installed anywhere on the system. This is 
really not your place to make this decision. Naturally there are challenges to 
overcome but nothing really all that mind shattering.   Fix the code so it 
doesn't matter and let's move on down the road please.  
 
Ron 

Comment 85

[Alexander Opitz]

Hello Ron,

What is so hard about it?

1.) Why users are root?
2.) Why Linux users do not use there package manager?
3.) Normaly you install with a package manager, why should someone make an
installer?

There is normaly no reason for an installer and so the installer was untouched
all the years. There was nobody who looked in the code, who tested the code and
so on.

I'm new to mozilla, I've "add me" to mozilla and will try to get a better linux
installer (Which is a waste of time, cause you should use a package manager).

You have source? You mean you can do it? You are the best?

Why haven't haven't you add yourself to mozilla? Why you haven't correct this?

Comment 86

[Juergen Saar]

Hello Alexander,

the available mozilla-packages are horrible. Most of them
split the mozilla-dircetories across the sysstem. I've
spent a lot of time seaching then global plugin-directory
for mozilla from the mdk-package. Or if you look at the
german port from kairo.at: No Installer at all, only a tarball
with the binaries. Nothing for an ordery user. 

In principal you are right: mozilla.org should bring 3 types
of linux-installer:

1) the one like it is now
2) rpm
3) deb

To your question to Ron: Some people only have enough time
for testing but not for programming ...

Greets
Juergen

Comment 87

[Helge Hielscher]

I have to second Alexanders opinion. Not using the packet manager should not be
the way to install packages for joe user.
Windows like installation programms only look like beeing an easy way to do an
installation, but aren't because they often damage the system integrity
bypassing the packet manager database.

IMHO mozilla.org should provide:
-no windows like installer
-RPMs/DEBs (could be provided by the distribution, like they do for KDE)
-binary files (.tar.gz) for admins and advanced users

@juergen:
finding the plugin directory is very easy, see yourself:
$ rpm -ql mozilla|grep plugin
/usr/lib/mozilla-1.5/components/libgkplugin.so
/usr/lib/mozilla-1.5/plugins
/usr/lib/mozilla-1.5/plugins/libnullplugin.so
/usr/lib/mozilla-1.5/searchplugins
/usr/lib/mozilla-1.5/searchplugins/NetscapeSearch.gif
/usr/lib/mozilla-1.5/searchplugins/NetscapeSearch.src
/usr/lib/mozilla-1.5/searchplugins/bugzilla.gif
/usr/lib/mozilla-1.5/searchplugins/bugzilla.src
/usr/lib/mozilla-1.5/searchplugins/dmoz.gif
/usr/lib/mozilla-1.5/searchplugins/dmoz.src
/usr/lib/mozilla-1.5/searchplugins/google.gif
/usr/lib/mozilla-1.5/searchplugins/google.src
/usr/lib/mozilla-1.5/searchplugins/lxrmozilla.gif
/usr/lib/mozilla-1.5/searchplugins/lxrmozilla.src
/usr/lib/mozilla-1.5/searchplugins/mdkbugzilla.gif
/usr/lib/mozilla-1.5/searchplugins/mdkbugzilla.src
/usr/lib/mozilla-1.5/searchplugins/mozilla.gif
/usr/lib/mozilla-1.5/searchplugins/mozilla.src
/usr/lib/mozilla/plugins

exactly two plugins directories: one for all versions of mozilla, one for 1.5

Comment 88

[timeless]

a few points in no particular order
1. there are probably at least 5 directories where mozilla will check for
plugins on unix. you might have found 2 of them, congrats.

2. the binary installer on windows is not particularly better than the one for
unix, nor is it particularly more welcome than the unix one. correct apps for
windows should be packaged as .msi files. This allows fairly decent integrity
and might be somewhat forward scalable.

Having just visited a wXP machine starting this week i'd like to note that it
suffers from a collection of evil/broken installers, not just mozilla's (which
other than the ability to try to roast n7.1 - which would almost certainly fail
miserably since this is XP and n7.1 is owned by a god which i am not).

3. That said, what in the world is an ordinary user?

I consider myself on this wXP box to be an ordinary user. I'm a mortal, I don't
know the root (Administrator) password, nor am I allowed to be that user.

Having tried to use debian, redhat and solaris packages as a mortal, I can
assure you that they suck. At least an installer will usually (* yes, I've seen
installers which don't, but generally they're rather amusing ones for windows,
not ones written for unix) ask you if you want to install something elsewhere.
Generally mortals (and you immediately lose your mortal status the moment you
disassemble a package) are forced to convert the packages to a cpio/tarball
format and expand them manually, in the case of solaris I had to write a script
which applied permissions flags, I can imagine needing to do the same thing for
rpm/deb (e.g. manually running [possibly through coercion] the post processing
scripts).

> but aren't because they often damage the system integrity
> bypassing the packet (sic) manager database.

Windows installers and the mozilla installer let you specify a destination (this
is good for mortals) and let you select which features you want (this is also
good for end users, *if* they perhaps have some other application which handles
a feature *and* the app they're installing can cooperate with that other
application).

Anyway, this bug is about implementing surgical strike, it isn't about not
having an installer, nor is it about having vendors make decent packages of
mozilla. For that there are sites like http://bugzilla.redhat.com and
http://bugs.gentoo.org/

Comment 89

[Alexander Opitz]

So now I'll put here some plans for discussion:

for 1.6:

+ add the problem to the release notes (also for the win[/MAC?] installer)
+ change the delete Message to point to the user, that we will remove ALL data
in this directory. (Maybe we need fixing the bug on this dialog first)

for 1.7:

+ read the install.log and only delete the files which are found in install.log.
The problem there is, if the user had installed special extensions/plugins.
(Should the directories deletet or not?)
+ Don't delete the directory if there is no install.log

After bsmedbergs changes to a new extension system we need a new way (but this
should be easy after the changes).

If this is ok, we should obsolate the old patch (but some things seem to be
usefull for a installer cleanup) change Target Milestone and add the relnote
keyword.

Comment 90

[Robert Parenton]

I would recommend that any user generated content (plugins and extensions) be
left in place, as that is the behavior for most uninstallers/upgrades.  Better
though would be a dialog that prompts the user if they wish to remove all
installed plugins and extensions (with a list of the files and directories) if
anything is found that is not listed in install.log (assuming that route is taken).

Comment 91

[Davide Bolcioni]

Having been bitten by this bug on a test machine, I would like to add some 
perspective. On Linux (Unix) executables are either (1) installed by root for
all users or (2) installed by each user in a home directory. The case (1) is
nowadays more or less covered by package managers; a Mozilla installer might
concentrate on case (2).

In the short term, I would suggest that the Mozilla installer should simply
refuse to run as root. A more discriminating approach might be to refuse to run
as root if a package manager is recognized: the rationale being that the system
is not "yours", and if unable to adapt with its policies (such as package
management) it is better to say so upfront.

In the longer term, a Mozilla installer for case (1) would have to address a
number of concerns, the foremost being respecting the target system and
adapting to its policies. For example:
- Unix software is expected to be split across multiple directories, most of
  which are essentially read-only after installation;
- the administrator is not required to specify a target directory, the software
  is expected to offer a sensible standard layout, e.g. the FHS;
- installation should not require any interaction with a living person pushing
  buttons and answering questions;
- installation should not require X11 or a GUI (running the browser would);
- installation should not require execution of code or scripts, as this might
  cause a root compromise.

Most of the above do not apply to case (2), in my opinion, and as such the
'installer' concept as lifted from Windows platforms might find it easier to
achieve its goal. The only exception might be that old Unix hands might find
annoying to find everything under ~/mozilla instead of ~/bin, ~/lib and the
like.

Comment 92

[Benjamin Smedberg]

re: comment #90, we tried not-deleting extensions on windows; it hasn't worked
and has been the cause of hard-to-diagnose crashes. In a future (firebird) world
extensions will be installed in the profile with good version management and
component enable-disable switches, but until that happens we're stuck with
deleting everything.

Comment 93

[chris hofmann]

asa has this on the 1.6 release note radar and will get it posted.

we need to settle on how to deal with this and try and get something done for
1.7, even though it looks like all the suggestions so far have side effects with
problems.

Comment 94

[Alexander Opitz]

chris: Would be nice if we can change the now existing sentence for 1.6 with a
better one (and not only be in the release note).
On Linux installer it is now:
"An older installation of Mozilla was detected.  Please choose to delete the
directory contents of your current Mozilla installation by pressing the 'Delete'
button.  Alternatively, please press the 'Cancel' button and choose a different
destination directory.  "
Maybe change to:
"An older installation of Mozilla was detected. Please press the 'Cancel' button
and choose a different destination directory or press the 'Delete dir' button to
remove the complete directory.   "

Change Button from "Delete" to "Delete directory".

For 1.7 we need something better ... but what? I don't know yet, but I think
following:

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.

If there is an installer.log and it is a release with bsmedbergs changes then we
can make an update plan.


Comments on this are welcome.

Comment 95

[Alexander Opitz]

1.6 is released now ... no information in the relnotes (so far I can see).
Also no comments to the proposed changes.

Comment 96

[Robert Parenton]

Comment #94 sounds like the best plan, although I would go one step farther and
allow the user to selectively delete any plugins/extensions left over directly
from the installer.

Comment 97

[Timothy M. Crider]

I was just reading about how Oracle is going to be allowing Mozilla to run 
Oracle applications later this year. Do you think this bug will be fixed by 
then? If not what is going to happen if someone tries to upgrade and loses all 
of their oracle apps in the process?

Would it be best to have the oracle team help with this bug?

Comment 98

[Alexander Opitz]

I would change the message to:

Message=A previous Mozilla installation has been found in the choosen directory.
To delete $s completely, please press 'Delete Directory' button. Your Mozilla
profile(s) information will not be affected. Alternatively, please press the
'Cancel' button and choose a different destination directory.

DELETE_LABEL=Delete Directory

if this is ok for all and makes the thing more clear on this point.

Comment 99

[Alexander Opitz]

Attachment: patch -u8p (trunk)

changes the text in dialog and on button to be more clear on this point.

The discussion on what the installer should do, or how to uninstall must go on,
so the patch do not resolve the bug.

Comment 100

[Christian :Biesinger (don't email me, ping me on IRC)]

+          snprintf(msg, 1024, currLC->GetMessage(), gCtx->opt->mDestination);
please use sizeof(buf) instead of 1024

Comment 101

[Alexander Opitz]

Comment on attachment 141152 [details] [diff] [review]
patch -u8p (trunk)

biesi yes that's right,

also 'char msg[1024];' should be 'char msg[MAXPATHLEN + 512];'

will be updated if 233763 is applied.

Comment 102

[Alexander Opitz]

Attachment: patch v2

updated patch

@biesi

done

Comment 103

[Alexander Opitz]

Attachment: patch v2.1

text reviewed by timeless on irc :-)

Comment 104

[Andrew Schultz]

Comment on attachment 141314 [details] [diff] [review]
patch v2.1

>Information in your Mozilla profile(s) information should not be affected.

Information in your Mozilla profile(s) should not be affected.

Comment 105

[Daniel Veditz [:dveditz]]

Comment on attachment 141314 [details] [diff] [review]
patch v2.1

r/sr=dveditz for this dialog text change. Just to be clear to any bug watchers:
this does not fix the bug, merely makes what is about to happen clearer.

Please fix "Information... information" as noted by Andrew. Don't need to see
another patch for just that.

Comment 106

[chris hofmann]

Comment on attachment 141314 [details] [diff] [review]
patch v2.1

a=chofmann for 1.7a

Comment 107

[Michiel van Leeuwen (email: mvl+moz@)]

patch v2.1 checked in.

Comment 108

[chris hofmann]

let's mark as fixed so it gets on testing radar.

Comment 109

[Jesse Ruderman]

chofmann: is there a new bug filed for fixing the original bug?

Comment 110

[timeless]

Bug 234479