233014 - default install into windows\program files directory, erases files

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Jim Harris]

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.

Comment 1

[Hermann Schwab]

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.

Comment 2

[Hermann Schwab]

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.

Comment 3

[Hermann Schwab]

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

Comment 4

[Hermann Schwab]

Attachment: GRE - install_status.log

Install_status.log from GRE:

...

Uncompressing Xpcom Succeeded: 0

    XPInstall Start
	Mozilla XPCOM: 0 OK
	Gecko Runtime Environment: -229 SCRIPT_ERROR
    XPInstall End

Comment 5

[Hermann Schwab]

Attachment: install_wizard.log from GRE

....
     [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

Comment 6

[Hermann Schwab]

Attachment: Mozilla - install_status.log

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

Comment 7

[Hermann Schwab]

Attachment: Mozilla install_wizard.log

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

Comment 8

[Hermann Schwab]

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.

Comment 9

[Hermann Schwab]

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

Comment 10

[Jacek Piskozub]

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!

Comment 11

[Jacek Piskozub]

Attachment: install_wizard.log from English Widnows

Found in c:\Program Files

Comment 12

[Jacek Piskozub]

Attachment: install_status.log from English Windows

Also from c:\Program Files\

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

Just lost all program files. - meaby stop pulling Windows Installer builds until
fixing it? 

Comment 14

[Matthias Versen [:Matti]]

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) ?

Comment 15

[Matthias Versen [:Matti]]

-> installer

Comment 16

[Jacek Piskozub]

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?

Comment 17

[Charles Fenwick]

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

Comment 18

[Dean Moncaster]

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! :)

Comment 19

[Dean Moncaster]

  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????

Comment 20

[Vedran Miletic]

(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.)"

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

When, exactly, were the last builds known to work and the first builds known to
be broken?

Comment 22

[Jacek Piskozub]

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."

Comment 23

[Hermann Schwab]

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

Comment 24

[Jacek Piskozub]

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.

Comment 25

[Benjamin Smedberg]

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.

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 27

[Curtis Williams]

Spent the morning re-installing my apps after the install wiped them out on NT
4.0 SP 6a.

Comment 28

[Hermann Schwab]

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 [e-mail]/[e-mail], r=neil sr=alecf

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 30

[Benjamin Smedberg]

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?

Comment 31

[Daniel (Leaf) Nunes]

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).

Comment 32

[Hermann Schwab]

(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.

Comment 33

[Daniel (Leaf) Nunes]

Attachment: chomp the buildID

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.

Comment 34

[Daniel Veditz [:dveditz]]

making this a 1.7a blocker pending further drivers discussion

Comment 35

[Thomas 'PointedEars' Lahn]

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.

Comment 36

[Zibi Braniecki [:zbraniecki][:gandalf]]

Benjamin: but how it's possible if no patch in this timeframe targeted this file?!?

Comment 37

[Alexander Opitz]

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)

Comment 38

[lohphat]

2004020508 win32 build installed fine, no casualties.

I still blame leaf.

Comment 39

[Zibi Braniecki [:zbraniecki][:gandalf]]

WFM too. Anything was fixed in last hours?

Comment 40

[Zibi Braniecki [:zbraniecki][:gandalf]]

agh. ok. - found reason - sorry for spam.

Comment 41

[Daniel (Leaf) Nunes]

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.

Comment 42

[Bryan]

Hi,
Maybe we can drop the installers and just go with .zip builds.
Although it seems to de fixed.

Comment 43

[lohphat]

What about bug 200297 handling of improperly terminated entries causing havoc? 
Would that be an easy catch as well?

Comment 44

[Hermann Schwab]

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 45

[Daniel Veditz [:dveditz]]

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

sr=dveditz assuming Sean's r=

Comment 46

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

Comment 47

[Sam Katz]

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.

Comment 48

[Daniel (Leaf) Nunes]

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).

Comment 49

[Daniel (Leaf) Nunes]

fix checked in.