Closed Bug 239722 Opened 18 years ago Closed 18 years ago

Firefox install deletes windows system files

Categories

(Firefox :: Installer, defect, P1)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED
Firefox0.9

People

(Reporter: dveditz, Assigned: bugs)

Details

(Keywords: dataloss, Whiteboard: fixed0.9,fixed-aviary1.0)

Attachments

(1 file, 2 obsolete files)

toolkit has its own copy of the windows installer, needs its own fix for
potentially system-corrupting bug 236312.
This should probably block 0.9

Most people won't have a problem, but anyone who has installed something
else--especially a windows update--prior to installing Firefox/Mozilla in the
same session is at risk.
Severity: normal → critical
Flags: blocking0.9?
This is my account of bug #239722 in my WinXP Home box.
In the same session Firefox (20040403 I think) and ran Windows Update. I don't
recall in what order but it must have been Windows Update first and FF second
from comment #1 above.
After a reboot, before I ever got the login window, I was greeted with a warning
that there was a problem finding SHELL32.DLL. Upon clicking the OK button, the
machine hanged. I rebboted again and chose "My Last Known Good Configuration"
from the login screen, which worked since I was able to login now and didn't get
the warning.
However, after I entered my username and password the system failed to login
properly. I only got the background and the menu bar at the bottom and nothing
else. Mouse pointer moved OK, but it was unresponsive to mouse clicks. My best
guess is that explorer.exe failed to load correctly. I Ctrl+Alt+Del, logged off
and logged back in. This time, no problem.
One question, I just installed 20040405 Firefox/0.8.0+ using official installer.
But there are no pending rename operations found in the registry, will I still
face this bug?
No need to worry then. The corruption happens if there was data already in the
registry from a previous install in the same session.

To save people linking back to the original bug for the scenario
   1. Install something (e.g. windows update) resulting in a
      prompt to reboot/restart the system now
   2. Cancel the prompt, intending to reboot later
   3. Install Firefox (or Mozilla)
Result:
   - Any pending file renames from the first install are converted
     into deletions of the target file. In the windows update case
     these are typically critical windows system libraries.
Recomendation for possible quick-fix, for those that install nightly buids
without paying attention to any build notes.

Just put a test in to see if there are any pending files, and then refuse to
install until the system is rebooted.  It is an old trick, that modern programs
really should have in final, but for an interim fix for nightlies, it would work.
For everyone who's not sure: just reboot before you install the nightly.
Re: comment #5:

Recent releases from MS using their Windows Installer sometimes give a message that:
"A previous install has not yet completed. The previous install needs to restart
the computer before it completes. Once this computer has been restarted, please
run this installer again to install product_name."

With a close button only.

This should happen in the Firefox installer if it detects a previous install, as
in comment #5.
Flags: blocking0.9? → blocking0.9+
camecek, did you think that no one would notice that you set blocking0.9 flag
back to +? If you try it again then someone should probably revoke your Bugzilla
privelidges. As it stands, you're a good candidate for that anyway.

Setting back to blocking0.9?
Flags: blocking0.9+ → blocking0.9?
(In reply to comment #8)
> camecek, did you think that no one would notice that you set blocking0.9 flag
> back to +? If you try it again then someone should probably revoke your Bugzilla
> privelidges. As it stands, you're a good candidate for that anyway.
> 
> Setting back to blocking0.9?

It's probably unclear why I'm being this curt. He's done this before in bug
240367 and has done it again, despite being told not to.
Keywords: dataloss
definitely a blocker, the fix for 236312 is a good start, once there's progress
there we can port the patch in question.  If not, we should have a band-aid for 0.9
Flags: blocking0.9? → blocking0.9+
Boing. 0.9
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox0.9
The revised patch from bug 236312 (attachment 148094 [details] [diff] [review]) will fix Firefox.
Comment on attachment 148446 [details] [diff] [review]
Patch for toolkit from seamonkey patch

This patch caused problems (StrStrI doesn't seem supported on some windows
systems contrary to msdn docs). r-, incorporate the re-fix from bug 243373
Attachment #148446 - Attachment is obsolete: true
Attachment #148446 - Flags: review-
Attached patch Patch 2 (obsolete) — Splinter Review
Combined patch from the two bug reports.

Tested under VC++ 6
Attachment #148458 - Flags: review?(dveditz)
Comment on attachment 148458 [details] [diff] [review]
Patch 2

The perils of a -w diff (in the other bug) -- you need to indent the block
inside the if(strstr()).

with that change, sr=me fwiw. In toolkit you need a peer r=
Attachment #148458 - Flags: superreview+
Attachment #148458 - Flags: review?(mconnor)
Attachment #148458 - Flags: review?(dveditz)
Attachment #148458 - Attachment is obsolete: true
Attachment #148462 - Flags: superreview?(dveditz)
Attachment #148462 - Flags: review?(mconnor)
Comment on attachment 148462 [details] [diff] [review]
Patch 2 with whitespace fixes

kicking this to ben since my installer-fu is weak like little girl, but this
looks to be a straight port of dveditz's patch, so I'm half-inclined to
rubber-stamp this based on having seen all of the review comments in the other
bug

carrying over dveditz's SR
Attachment #148462 - Flags: superreview?(dveditz)
Attachment #148462 - Flags: superreview+
Attachment #148462 - Flags: review?(mconnor)
Attachment #148462 - Flags: review?(bugs)
Comment on attachment 148462 [details] [diff] [review]
Patch 2 with whitespace fixes

I'm going to rubber stamp thsi since I never modified any of this code in fx's
version so the reviews from the source bug carry over.
Attachment #148462 - Flags: review?(bugs) → review+
checked in branch and trunk
Whiteboard: fixed0.9
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
The branch checkin missed the AVIARY_1_0_20040515_BRANCH.
Whiteboard: fixed0.9 → checkin0.9
checked in on the aviary branch
Whiteboard: checkin0.9 → fixed0.9
Attachment #148458 - Flags: review?(mconnor)
Whiteboard: fixed0.9 → fixed0.9,fixed-aviary1.0
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.