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.
reassigning to sgehani
Assignee: ssu → sgehani
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Installer deleted every file in /usr → Employ surgical upgrade strategy
*** Bug 76748 has been marked as a duplicate of this bug. ***
*** Bug 82872 has been marked as a duplicate of this bug. ***
*** Bug 84701 has been marked as a duplicate of this bug. ***
*** Bug 90327 has been marked as a duplicate of this bug. ***
adding (install deletes /usr or /usr/bin files) to summary so that it turns up on more searches
Summary: Employ surgical upgrade strategy → Employ surgical upgrade strategy (install deletes /usr or /usr/bin files)
this is a baddie. Is there a release note? (If not please add at least relnote keyword)
*** Bug 97318 has been marked as a duplicate of this bug. ***
Assignee: sgehani → syd
*** Bug 92462 has been marked as a duplicate of this bug. ***
I think this is of interest to nsenterprise.
Assignee: syd → curt
*** Bug 102177 has been marked as a duplicate of this bug. ***
Link to doc added.
Summary: Employ surgical upgrade strategy (install deletes /usr or /usr/bin files) → [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files)
*** Bug 113248 has been marked as a duplicate of this bug. ***
Summary: [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files) → META: [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files)
Summary: META: [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files) → [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files)
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.
*** Bug 120389 has been marked as a duplicate of this bug. ***
assigning to me
Summary: META [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files) → [rfe] [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files)
Not sure how this missed the nsbeta1 nomination list.
Assignee: curt → syd
Status: ASSIGNED → NEW
minusing, won't do for MachV
*** Bug 125440 has been marked as a duplicate of this bug. ***
*** Bug 125985 has been marked as a duplicate of this bug. ***
*** Bug 130561 has been marked as a duplicate of this bug. ***
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
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.
Wow, are you serious?
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
blizzard - it honestly wiped my /usr/lib
*** Bug 144888 has been marked as a duplicate of this bug. ***
*** Bug 145038 has been marked as a duplicate of this bug. ***
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.
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.
targetting for 1.01; drivers would like this fixed in that timeframe
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.
Attachment #84879 - Attachment is obsolete: true
*** Bug 146812 has been marked as a duplicate of this bug. ***
> 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?
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".
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'
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.)
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.
> but it's available only to Netscape employees. What?
Well... what does "http://puma/xpinstall/UpgradeOptions.html" mean then?
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).
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 =).
Attachment #84950 - Attachment is obsolete: true
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.. :)
Please, could someone review this?
*** Bug 148834 has been marked as a duplicate of this bug. ***
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".
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
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?
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.
*** Bug 154593 has been marked as a duplicate of this bug. ***
*** Bug 155208 has been marked as a duplicate of this bug. ***
*** Bug 159678 has been marked as a duplicate of this bug. ***
*** Bug 160708 has been marked as a duplicate of this bug. ***
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:-(
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:-(
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...
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: critical → enhancement
Summary: [rfe] [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files) → [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files)
*** Bug 176478 has been marked as a duplicate of this bug. ***
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.
This is not an enhancement -> restoring severity to critical.
Severity: enhancement → critical
*** Bug 183938 has been marked as a duplicate of this bug. ***
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.
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 firstname.lastname@example.org
*** Bug 197371 has been marked as a duplicate of this bug. ***
*** Bug 202502 has been marked as a duplicate of this bug. ***
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
> 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/
*** Bug 209677 has been marked as a duplicate of this bug. ***
*** Bug 210969 has been marked as a duplicate of this bug. ***
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 ???
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.
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
*** Bug 211601 has been marked as a duplicate of this bug. ***
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.
*** Bug 226370 has been marked as a duplicate of this bug. ***
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
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. .
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!!!!!!!!!
Assignee: syd → opi
Status: ASSIGNED → NEW
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
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
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?
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
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
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/
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.
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).
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.
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.
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.
Flags: blocking1.6? → blocking1.7a+
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.
1.6 is released now ... no information in the relnotes (so far I can see). Also no comments to the proposed changes.
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.
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?
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.
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.
Attachment #85483 - Attachment is obsolete: true
+ snprintf(msg, 1024, currLC->GetMessage(), gCtx->opt->mDestination); please use sizeof(buf) instead of 1024
Comment on attachment 141152 [details] [diff] [review] patch -u8p (trunk) biesi yes that's right, also 'char msg;' should be 'char msg[MAXPATHLEN + 512];' will be updated if 233763 is applied.
updated patch @biesi done
Attachment #141152 - Attachment is obsolete: true
text reviewed by timeless on irc :-)
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 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 on attachment 141314 [details] [diff] [review] patch v2.1 a=chofmann for 1.7a
Attachment #141314 - Flags: approval1.7a? → approval1.7a+
patch v2.1 checked in.
let's mark as fixed so it gets on testing radar.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
chofmann: is there a new bug filed for fixing the original bug?
Status: RESOLVED → VERIFIED
Summary: [LINUX]Employ surgical upgrade strategy (install deletes /usr or /usr/bin files) → [LINUX]Warn users about the directory we're going to wipe out before we do it (e.g. /usr or /usr/bin)
Target Milestone: mozilla1.0.1 → mozilla1.7alpha
You need to log in before you can comment on or make changes to this bug.