Closed Bug 233014 Opened 21 years ago Closed 20 years ago

default install into windows\program files directory, erases files

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jimh, Assigned: leaf)

References

Details

(Keywords: dataloss, regression, smoketest)

Attachments

(7 files)

GRE - install_status.log
2.27 KB, text/plain
Details
install_wizard.log from GRE
5.99 KB, text/plain
Details
Mozilla - install_status.log
3.43 KB, text/plain
Details
Mozilla install_wizard.log
15.14 KB, text/plain
Details
install_wizard.log from English Widnows
15.19 KB, text/plain
Details
install_status.log from English Windows
2.93 KB, text/plain
Details
chomp the buildID
479 bytes, patch
ssu0262
: review+
dveditz
: superreview+
Details | Diff | Splinter Review 
User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040203

I downloaded the latest Win32 installer from this
location--http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-02-03-18-trunk/mozilla-win32-installer.exe
and ran the program. Nothing seemed to be happening. I happened to be in my
program files directory and noticed files and folders were being erased. I
aborted the installation as quickly as possible but about half of my program
files directory was erased. I'm not going to run that particular installer again
to see if I can reproduce the results

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
confirming error using BuildID 2004020400 on win98SE, full installer.

Install path offered should be c:\programme\mozilla.org\trunk, as there was my
latest installation, but I got offered c:\programme, that is the default windows
directory for installing programs.

I selected manually the correct directory, and my old mozilla was deinstalled,
but the new one wasn´t installed, instead I got 2 script errors, latest was -211.

I then created an empty folder in c:\programme, and tried to reinstall into this
empty folder. I got the standard message that a previous installation had been
found in this (empty!) folder an Mozilla would delete all files.
I acknowledged, and Mozilla aborted with same -211 message.

Blocker, as there is dataloss, and I can´t test, if I can´t install.
I´m not sure about the category, if this is a Build Config or an Installer bug.
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
Summary: installer erases files in program files directory → default install into windows\program files directory, erases files
regression: BuildID 2004020311 ok, BuildID 2004020317 regressed.

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-02-03-18-trunk/

starting mozilla-win32-installer.exe tells it will install BuildID 2004020317,
suggests windows programs directory for install, tells it found an installation
there, and will delete the files. I denied, and selected another, empty
directory, it tells it found an Moziila installation there and will delete it. 
I acknowledged, Mozilla went on, and aborted.

1st error message, shown very shortly: -229 GRE Script Error
2nd error message, replaced the first: -211 Navigator Installation not started.
Keywords: regression
*** Bug 233034 has been marked as a duplicate of this bug. ***
Install_status.log from GRE:

...

Uncompressing Xpcom Succeeded: 0

    XPInstall Start
	Mozilla XPCOM: 0 OK
	Gecko Runtime Environment: -229 SCRIPT_ERROR
    XPInstall End
....
     [13/13]	Installing: C:\Programme\Gemeinsame
Dateien\mozilla.org\GRE\1.7a_2004020317\mozz.dll
     ** performInstall() returned: 0

     Install completed successfully  --  02/04/2004 11:50:04

-------------------------------------------------------------------------------

  --  02/04/2004 11:50:04
-------------------------------------------------------------------------------


     ** Line: 0 can't convert Error to string
     ** Line: 136	unterminated string literal

     Install **FAILED** with error -229  --  02/04/2004 11:50:04
install_status.log after some retries to install into a dummy directory.
The original installation remained untouched.

...
     ** File to delete: c:\Programme\mist\components\p3p.dll\
     ** addDirectory() of Program returned: -211

     Install **FAILED** with error -211  --  02/04/2004 12:07:36
This is from install_wizard:

     ** File to delete: c:\Programme\mist\components\p3p.dll\
     ** addDirectory() of Program returned: -211

     Install **FAILED** with error -211  --  02/04/2004 12:07:36

this was the end of install_status.log

    uncompressing GRE: 0
    launching GRE

    Uncompressing Xpcom Succeeded: 0

    XPInstall Start
	Navigator: -211 INSTALL_NOT_STARTED
    XPInstall End
End Log: 04.02.04 - 12:07:47
checked in in that timeframe, and changed some install paths?
Bug 230468 RFE: mozilla should provide a simple way to run custom shell scripts
at mozilla startup and shutdown

BuildID 2004020317 from zipfile is working:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-02-03-18-trunk/
mozilla-i686-pc-cygwin.zip       03-Feb-2004 18:05  10.4M

It is using the Flash plugin installed in Opera, and uses the plugins from the
standalone Java and Acrobat installations, seems to work as expected.

*** Bug 233011 has been marked as a duplicate of this bug. ***
The Program Files directory is not cleaned if you choose "Skip" during the
installation. I was lucky :-) 

However, this build should be deleted from the FTP server ASAP!
Found in c:\Program Files
Also from c:\Program Files\
Just lost all program files. - meaby stop pulling Windows Installer builds until
fixing it?
Flags: blocking1.7a?
Flags: blocking1.4.2?
and why is this in browser general ?
Did you checked the 1.4.2 branche before you set the flag ?
removing flags and set "smoketest" (is this still valid) ?
Flags: blocking1.7a?
Flags: blocking1.4.2?
Keywords: smoketest
-> installer
Assignee: general → general
Component: Browser-General → Installer
QA Contact: general → bugzilla
Matti: No, I didn't. But why on all Mozilla gods did you delete "blocking1.7a?"
flag? Do you really believe that we should ship 1.7alpha with this bug?
Component: Installer → Browser-General
Flags: blocking1.7a?
Component: Browser-General → Installer
*** Bug 233056 has been marked as a duplicate of this bug. ***
i was hit by this too, my friend did warn me about mozilla ruining systems but 
alas i didn't believe him, i wish i had! :)
  Files/Dirs deleted on upgrade:
    failed: C:\Program Files\Adobe\
    failed: C:\Program Files\BreakPoint Software\
    failed: C:\Program Files\Common Files\
    failed: C:\Program Files\GetRight\
    failed: C:\Program Files\Google\
    failed: C:\Program Files\GTA\
   skipped: C:\Program Files\install_status.log
        ok: C:\Program Files\install_wizard.log
    failed: C:\Program Files\Internet Explorer\
    failed: C:\Program Files\Java\
        ok: C:\Program Files\Microsoft ActiveSync\
    failed: C:\Program Files\microsoft frontpage\
    failed: C:\Program Files\Microsoft Office\
    failed: C:\Program Files\Microsoft Visual Studio\
   skipped: C:\Program Files\mozilla.org
    failed: C:\Program Files\NetMeeting\
    failed: C:\Program Files\ORL\
    failed: C:\Program Files\Outlook Express\
   skipped: C:\Program Files\plugins
    failed: C:\Program Files\Pulse\
        ok: C:\Program Files\SengentD2OL\
    failed: C:\Program Files\Sophos SWEEP for NT\
    failed: C:\Program Files\Symantec\
    failed: C:\Program Files\Tray Wizard\
   skipped: C:\Program Files\uninstall
    failed: C:\Program Files\Uninstall Information\
    failed: C:\Program Files\Windows Media Player\
    failed: C:\Program Files\Windows NT\
        ok: C:\Program Files\WindowsUpdate\
        ok: C:\Program Files\WinZip\
        ok: C:\Program Files\WS_FTP Pro\

This is also in the update log. Why is it even traversing the program files dir 
and deleting things anyway? did no one test it before release to general 
testers????
(In reply to comment #19)
> This is also in the update log. Why is it even traversing the program files dir 
> and deleting things anyway? did no one test it before release to general 
> testers????

Nightlies are generated automatically, so, nobody tests them.

From http://www.mozilla.org/start/
"(Be warned that nightly builds are development software, and there is no
guarantee that they won't fry your processor, insult your mother, or cause you
to break out in a nasty rash.)"
When, exactly, were the last builds known to work and the first builds known to
be broken?
Verdan: Dean is not suing mozilla.org. 

The thing to do now is to delete this build from the FTP/WWW servers. The tree
is now frozen, which is good. But it also means that people will download the
disastrous build as the "latest" or "latest-trunk" until a new build appears.
Remember that we are supposed to be only a few days from a milestone build
(1.7alpha), so more people are testing the builds. We should not set a trap for
them, now that we know the build is rotten.

Last good build: 2004020308
First bad build: 2004020318

I do not see any suspicious checkins in those 10 hours. Matti (in private
communication) says that "there is something broken in teh backend."
Re comment 21:  David, see comment #2, comment #8

BuildID 2004020311 ok, BuildID 2004020317 installers broken, zip is working.

At first, some error happens at installing GRE, then the Navigator also produces
an error, aborts, and 2 error messages are shown, first is replaced
automatically by second message, 

1st error message, shown very shortly: -229 GRE Script Error
2nd error message, replaced the first: -211 Navigator Installation not started.

There is a DocWatson log from crash on WindowsNT in Bug 233011
http://bugzilla.mozilla.org/attachment.cgi?id=140563&action=view

I found a check-in in this timeframe, but don´t know, if it affects Windows.

Bug 230468 comment 8 From Christian Biesinger  2004-02-03 16:26 PST
Checking in Makefile.in;
/cvsroot/mozilla/xpfe/bootstrap/Makefile.in,v  <--  Makefile.in
new revision: 1.248; previous revision: 1.247
done
Checking in mozilla.in;
/cvsroot/mozilla/xpfe/bootstrap/mozilla.in,v  <--  mozilla.in
new revision: 1.4; previous revision: 1.3
done


I've looked into that checkin. It is really the only one having anything to do
with mozilla configuration. However there is nothing suspicious in changing the
string "mozilla-bin" to a variable in the list of places where startup scripts
should be run. Nothing to do with installer settings, at least.
The only suspicious bug I see is bug 202505, which landed 02/02/2004 08:47. 
However, I still fail to see how that would affect the installer default paths.

I would like people to report specifically on which windows OS they experience
this bug.
I renamed the builds in 2004-02-03-18-trunk and 2004-02-04-12-trunk by adding
-dangerous to the end of the filename, and removed them from latest/latest-trunk.
Spent the morning re-installing my apps after the install wiped them out on NT
4.0 SP 6a.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040203 BuildID 2004020311 

tested on Win98 SP1 and Win98SE

tested testcase of Bug 181336 as fixed with this build, test failed with earlier
build, so up to and including the following entry all seems to be ok.
build was a download from tinderbox CREATURE.
 
02/03/2004 10:27	dbaron%dbaron.org 	mozilla/ layout/ html/ base/ src/
nsTextFrame.cpp 	1.449 	1/1  	Uncomment a call to SetColor that is needed.
b=181336 r+sr=bzbarsky


I downloaded multiple tinderbox builds today, and tried to start.
I´m always using the full sized mozilla-win32-installer.exe for off-line
installation.
The broken builds always wanted to install in c:\windows\programs,
whereas my older installers still wanted to install in my lastused folder,
so I assume, they get this info from the profile, and the broken builds can´t
access the profile.
I also downloaded the zip versions of two broken installer builds, and the zips
ran fine.  mozilla-i686-pc-cygwin.zip 

Bugzilla Bug 232929 redeclaration of var prefs/ioService in offlineStartup.js 	

Found another check-in:
02/03/2004 16:58	cbiesinger%web.de 	mozilla/ xpfe/ components/ prefwindow/
resources/ content/ nsPrefWindow.js 	1.46 	6/1  	Bug 63117 Numbers in prefs
accepted in octal when started with 0 and hexadecimal when started with 0x
patch by eddyk@netscape.com/durbacher@gmx.de, r=neil sr=alecf
What is the significance of the checkins in comment 28?  Did you narrow down a
regression date?  If so, could you tell the rest of us?
OK, I think I have this tracked down. The gre.xpi file has a malformed
install.js script:

function registerKeys()
{
  var subkey;  //the name of the subkey you are poking around in
  var err;
  var winreg;
  var tmpstr;

  winreg = getWinRegistry();
  winreg.setRootKey(winreg.HKEY_LOCAL_MACHINE);

  createRootRegKey(winreg);

  subkey = regRootKey;
  err    = winreg.setValueString(subkey, "Version", "1.7a");
  err    = winreg.setValueString(subkey, "BuildID", "2004020411
");
  tmpstr = new String(fProgram);
  err    = winreg.setValueString(subkey, "GreHome", tmpstr.substring(0,
tmpstr.length-1));
  err    = winreg.setValueString(subkey, "GreComponentsDir", fProgram +
"Components");

The CR in the BuildID string wreaks havoc beyond my wildest imaginings. This
seems, then, to be a build-config or build-machine issue... perhaps related to
line endings somehow?
Assignee: general → leaf
Component: Installer → Build Config
QA Contact: bugzilla → bsmedberg
I suspect a path change on the system i made yesterday. Reverting (which will
re-break .zip file creation, which i'll find another workaround for).
Status: NEW → ASSIGNED
(In reply to comment #29)
> What is the significance of the checkins in comment 28?  Did you narrow down a
> regression date?  If so, could you tell the rest of us?

see my comment #2, comment 23:

regression: BuildID 2004020311 ok, BuildID 2004020317 regressed.

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-02-03-18-trunk/

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=02%2F03%2F2004+10%3A00&maxdate=02%2F03%2F2004+20%3A00&cvsroot=%2Fcvsroot

working BuildID 2004020311 includes the checkin for bug 181336 from 10:27
so regression area starts with next checkin at 02/03/2004 12:07

Build ID 2004020317 regressed, 
so latest check-ins  in this build may be one of these: 
02/03/2004 16:58 Bug 63117 Numbers in prefs accepted in octal...
02/03/2004 18:01 Bug 110584 Missing call to jsj_ExitJava use |break| ...
02/03/2004 19:10 Bug 197919 Non Mouse Click & Max Number of Popups Exceptions


significance of my naming check-ins is zero, as this is pure speculation, based
on the timeframe only, and some uneducated guessings about the workings of this
bug. I don´t understand enough of the code.
Component: Build Config → Installer
This is probably not the only fix needed if someone is using cygwin perl/utils
to generate installers on windows after installing cygwin with "unix" style
line endings, but it's a start.

I've reverted the path on the build system, so future builds will not have this
issue, but it would be good to bulletproof the installer creation system
against line ending issues caused by using cygwin perl/utils.
making this a 1.7a blocker pending further drivers discussion
Flags: blocking1.7a? → blocking1.7a+
Hi,

(add me.  I was one of the "lucky" guys who downloaded this build -- about 11
megs in vain, that really sucks with 56k (but OK, I know what night-lies ;-) are
and should've expected it).  I was even more lucky to change the setup target
dir which only killed my previous nightly as it was intended -- thanks $DEITY!)

I got the same errors (see <http://pointedears.de.vu/mozilla/nightly/buggy>). 
For I know the path is defined in the CONFIG.INI compressed in the installer
self-extractor, I decompressed (using the /u switch, see
<http://piology.org/mozilla/of-the-day.html>), looked into it and found that,
compared to the CONFIG.INI of the 1.7a-2004013008-win32 nightly, it had all
build-specific information, e.g. product name, version string, build ID aso.
replaced by the empty string.  But adding the appropriate data did not fixed the
final problem -- setup broke off with "Navigator: -211 INSTALL_NOT_STARTED".

Hope this gives you a clue of what went wrong, so that we have a *new* *working*
Windows build soon.


\V/ PointedEars

P.S.
You should add information to the nightly/2004-02-03-18-trunk dir (small .txt
file would suffice) explaining *why* this build is "-dangerous", maybe point to
this bug.
Benjamin: but how it's possible if no patch in this timeframe targeted this file?!?
How I see the problem correct:

Mozilla default install dir's is:

C:\{$PROGRAM}

the install fails and so mozilla removes all files in the install dir and so
removes all files in C:\{$PROGRAM} instead of removing only installed files.

This are 2 bugs:

1.) Why does installing break? (My be the build system)
2.) The removing of all files (as I predict in bug #69153)
2004020508 win32 build installed fine, no casualties.

I still blame leaf.
WFM too. Anything was fixed in last hours?
agh. ok. - found reason - sorry for spam.
Comment on attachment 140627 [details] [diff] [review]
chomp the buildID


To be clear, the build system change that caused the foul-up is fixed. This
patch is just to try and prevent extra line-ending/whitespace from causing
similar foulups in the future, with other seemingly harmless config changes.
Attachment #140627 - Flags: superreview?(dveditz+bmo)
Attachment #140627 - Flags: review?(ssu0262)
Hi,
Maybe we can drop the installers and just go with .zip builds.
Although it seems to de fixed.
What about bug 200297 handling of improperly terminated entries causing havoc? 
Would that be an easy catch as well?
According to the title, this bug seems to be fixed, for now.
As this bug is highly visible, and it´s title is now misleading, shouldn´t it be
resolved to 'fixed', and the remaining issues discussed in another bug?
I don´t want to see this bug still open days before launch of 1.7a, wouldn´t be
very motivating to give 1.7a a try.

This build also fixes a bug I´ve seen in the broken builds, i.e. when I dragged
a favicon from the Location Bar into my Personal Toolbar, or a folder therein,
Mozilla crashed, when I released the key to drop the bookmark to its place.

Comment on attachment 140627 [details] [diff] [review]
chomp the buildID

sr=dveditz assuming Sean's r=
Attachment #140627 - Flags: superreview?(dveditz+bmo) → superreview+
*** Bug 233359 has been marked as a duplicate of this bug. ***
I just wanted to add that I had bad experiences with Netscape 4.x where the 
uninstall application would launch to do a cleanup and fail, preventing me 
from installing the software. One machine was running windows 95 (I think) and 
another running Windows ME.

Lesson to me?

An application cannot be expected to "catch" errors in another 
process/application/API from a programming standpoint, but a user expects it 
to.

so please, do not launch a seperate process for clean-up tasks. Mozilla should 
also be nice and create a restore point before doing the install.


Taking off the blocker list, since the code fix is not strictly necessary (as
the build machine has been reverted to a state where this is no longer an issue).
Flags: blocking1.7a+ → blocking1.7a-
Attachment #140627 - Flags: review?(ssu0262) → review+
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: