Closed Bug 239722 Opened 18 years ago Closed 18 years ago
Firefox install deletes windows system 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
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.
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.
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+
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox0.9
Patch against toolkit from http://bugzilla.mozilla.org/attachment.cgi?id=148094&action=view
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
Combined patch from the two bug reports. Tested under VC++ 6
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=
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
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
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
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.