Closed Bug 314684 Opened 15 years ago Closed 15 years ago

Endless update loop from firefox 1.5 beta2 to 1.5 rc1 (finds and downloads an update, fails to apply, then prompts for re-download)

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
1.8.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: requiemcomic, Assigned: benjamin)

References

Details

(Keywords: fixed1.8, Whiteboard: See comment #63 for workaround)

Attachments

(5 files)

my last-update.log
15.00 KB, text/plain
Details
The contents of my C:\Program Files\Mozilla Firefox
20.15 KB, text/plain
Details
last-update.log after failed update
9.81 KB, text/plain
Details
They are directories, not files
1.63 KB, patch
axel
: review+
mscott
: superreview+
mtschrep
: approval1.8rc2+
Details | Diff | Splinter Review
The weird status bar
146.00 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051101 Firefox/1.6a1
Build Identifier: http://www.mozilla.org/products/firefox/releases/1.5beta2.html

Performed an autoupdate on 1.5 Beta 2 Firefox.  It first downloaded the update which was about 600kbs.  It then notified me that it was unable to install the downlaod due to the application being in use or a file being used.  Then Firefox attempted to download the full installation to correct the problem.  It then informed me that the fdownload could not be applied.



Reproducible: Sometimes

Steps to Reproduce:
1.Use check for updates function in Firefox 1.5 Beta 2
2.Follow the directions that are specified with the update.
3.



Expected Results:  
It then continously tried to reapply the updates over and over again.  I finally had to uninstall Firefox to resolve.  I have been able to reprodue it on one other computer so far.

Did the Autoupdate and let me know that I was now on RC1
I'm seeing this behavior as well.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
(In reply to comment #1)
> I'm seeing this behavior as well.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006
> Firefox/1.4.1
> 
Thanks...Good to know I wasn't losing my mind :)

I tried it another time after totally removing all registry entries and profile infor and had it happen again as well.
I also have this problem. No matter what I do, I can not update to RC1
This one WORKSFORME...

James, the buildId you posted is for a trunk build, not 1.5b2 like you said. Nathan's buildId is the correct one for 1.5b2.
Can you folks give us some details on your user lever and permissions?
Version: unspecified → 1.5 Branch
That would be "user level", by the way, not "lever". ;-)
*** Bug 314709 has been marked as a duplicate of this bug. ***
Confirming based on multiple comments made in other bugs as well as asa's rc1 blog comments ( http://weblogs.mozillazine.org/asa/archives/2005/11/firefox_15_firs.html ). I expect we'll see more dups shortly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Auto Update ThrowsFirefox into endless loop → Endless update loop from firefox 1.5 beta2 to 1.5 rc1 (finds and downloads an update, fails to apply, then prompts for re-download)
WFM. Could not reproduce. Installed only one partial update (WinXP).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Saw news that RC1 was out, selected Help - Check for Updates.  Firefox downloaded a ~600k update, asked me to quit, and showed a progress bar updating the browser.  When it relaunched, titlebar still said Beta 2.  Firefox then started downloading a 6mb file on its own, asked me to update, quit, ran the progress bar, and relaunched Beta 2 again.  Choosing update will loop the above process of first getting a 600k file.

Firefox is installed to c:\internet\firefox\ Permissions on the folder show I have full access.  I am logged in on a domain account with local admin access.  This started as a clean install of 1.5 Beta 1 and was self updated to Beta 2 with no issues.
Attached file my last-update.log — 
This is on a german windows XP, apparently update doesn't find firefox.

Could this be a problem with C:\Programme\Mozilla Firefox instead of Programs?
*** Bug 314719 has been marked as a duplicate of this bug. ***
blocking1.8rc2?
Flags: blocking1.8rc2?
Most of these reports talk about the en-US build on a non-default install 
location, either by (likely) using a localized version of windows, or having
a different install path (#10), btw.
Same behaviour as Tom in comment 10. I have admin rights on a german Win XP and installed it to c:\Programme\Mozilla Firefox which was the default install directory. My firefox build is a en-US version.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 ID:2005102519

Tried installing the en-US 1.5b2 in C:\Rare Naam but it updated succesfully.
Did some testing. Installed a b2 in a fresh dir and it doesn't contain the 
defaults/profile/extensions directory.

This seems to be one incarnation of the "updater can't remove directories" 
problem. What puzzles me is, I don't see the attempt to remove searchplugins
in my log.

http://lxr.mozilla.org/mozilla1.8/source/browser/installer/removed-files.in#15 vs
http://lxr.mozilla.org/mozilla1.8/source/browser/installer/removed-files.in#24

The only difference I see is the trailing '/', does the code skip those 
automatically? (I don't see the updater code doing so, though.)

Darin? And, is there a bug to add rmdir?
Oops, forget to add, I could update allright a *really fresh* (TM) install in
c:\Programme\Neuer Ordner
*** Bug 314736 has been marked as a duplicate of this bug. ***
Hello,

I can confirm this here (Windows XP US, Windows XP MCE US, both with swiss german locale. Custom Installation, but with default location). Both installations failed, with some slight differences.

First the MCE installation:

*) I used "Check For Update". It told me that Firefox 1.5 is available. 
*) It began downloading the small patch.
*) Without any notice, it began downloading the bigger patch.
  -> I noticed that the details-Link has no effect
*) Mozilla restarted. Beta 2 came up. Update failed silently.

The XP Pro installation was hairyier:

1) "Check For Update". It told me that the update was available
2) Download of small patch.
3) Notice: Can't install small patch. Trying big one
4) Firefox restarts
5) Error about being unable to replace some files. I should check permissions (which I did. I also assured that no process was accessing any Firefox related directory). 
6) I clicked OK and a progress dialog about trying to install updates popped up and went to 100%
7) goto 5. After two iterations: Remove all extensions and try again. No change

I ended this by just rebooting the system (I feared some file was still in use - even though I found nothing in Process Explorer).

Launching Mozilla brought up the same Error-Message, the same progress dialog, but then, finally, RC1 launched.

Typing this in RC1.

Guys. This MUST BE FIXED. I'm trying to imagine my parents auto-updating their installation and I'm seeing frightening pictures involving me to travel some 30 kilometres to fix it for them. Quite selfish. I know. Please don't make me go to my parents to fix their installation ;-)

Eek

which logfile do you need me to attach?

Philip
I'm running on Windows XP Pro, under a user account with admin rights. Install directory is "C:\Program iles\Mozilla Firefox".
For what it's worth, here's the contents of my C:\Program Files\Mozilla Firefox directory.

My installed extensions: http://img498.imageshack.us/img498/4778/extensions1nc.png
My installed themes: http://img498.imageshack.us/img498/2955/themes5nx.png
Nathan is seeing the same thing as I do, from his attachement, 
Directory of C:\Program Files\Mozilla Firefox\defaults\profile\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}

To all, could you check whether you have the directory above in your install dir?

(In reply to comment #23)
Before updating? No, there's no folder extensions in the folder profile.
Ria, could you check whether you have
updates/last-update.log
in your Firefox program directory and attach that?
If not, create a dummy file and try to update again (bug 313963 ain't fixed in
RC 1 yet)? 
Is any thought being given to backing this "update" feature out for 1.5 release? It hasn't yet worked well.
shows a lot of "file cannot be removed because it does not exist; skipping" messages.
Same for me (tries small update, then large, returns as Beta2)

I also noticed that even though the version I installed in 1.5 Beta2 after doing the update I have this:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

??  And in Add Remove programs it is Mozilla Firefox(1.4.1) but it wasn't before.
Was the wrong version placed in the update hopper?  I'm going to reinstall Beta2 and check this out.
I can confirm Ria's experience. A clean install of en-US 1.5b2 on English windows updates fine to 1.5rc1. The install doesn't contain defaults/ profile/ {972ce4c6-7e08-4474-a285-3208198ce6fd} directory before or after the update.

But my 1.0.7 install does contain that directory and its install.rdf. Installing 1.5b2 over 1.0.7, and then trying to update fails as others have reported:
EXECUTE REMOVE defaults/profile/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
copy_file: failed to open or stat: -1,defaults/profile/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd},13
backup_create failed: 6
### execution failed

A tentative theory is that installing over the top of 1.0.x leaves behind the problematic files, and the updater does not handle their removal. 

[Attachment 201618 [details] is actually a successful update (see second last line), probably left over from a previous attempt - update log creation is broken in some builds (bug 313693). The "file cannot be removed because it does not exist; skipping" messages are normal.]
Comment on attachment 201618 [details]
last-update.log after failed update

Greg, looking at your last-update.log, that succeeded:

>succeeded
>calling QuitProgressUI

The "skip"s are OK, those are just informative messages,
no real errors. It just means that the files that may
be required to be removed aren't there in the first place,
as it is commonly the case in rather fresh install dirs.
(In reply to comment #29)
> windows updates fine to 1.5rc1. The install doesn't contain defaults/ profile/
> {972ce4c6-7e08-4474-a285-3208198ce6fd} directory before or after the update.

After manual removal of the {972ce4c6-7e08-4474-a285-3208198ce6fd} directory from the firefox installation directory, the update runs through, firefox 1.5rc1 comes up afterwards and the last-update.log does say "succeeded".

The directory seems to be the culprit...
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #201625 - Flags: review?(darin)
Confirmed that 1.5a1, a2, b1, and b2 don't create defaults/profile/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/, and that 1.0.7 removes that directory on uninstall.
(In reply to comment #23)
> Nathan is seeing the same thing as I do, from his attachement, 
> Directory of C:\Program Files\Mozilla
> Firefox\defaults\profile\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}
> 
> To all, could you check whether you have the directory above in your install
> dir?
> 

Same result - that directory was present, and the installs failed in the same way as the other reports.  Removed the directory, ran the update check, and the install worked as expected.
Comment on attachment 201625 [details] [diff] [review]
They are directories, not files

http://lxr.mozilla.org/mozilla/source/tools/update-packaging/common.sh#76
is quite frank about this, r=me, sr? over to darin
Attachment #201625 - Flags: superreview?(darin)
Attachment #201625 - Flags: review?(darin)
Attachment #201625 - Flags: review+
I'm afraid I've deleted my C:\Program Files\Mozilla
> Firefox\defaults\profile\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd} directory and it still doesn't update for me. It doesn't find any updates at all.

Also I've created C:\Program Files\Mozilla Firefox\updates\last-update.log, but it doesn't get written to.
I see the same behaviour as Nick describes in comment #29.
I only use clean directories, so that's why I could not reproduce the bug.
When I installed 1.5 2b over the top of 1.0.6 I saw the same problem.
To summarize steps to reproduce on WinXP:

1. start with a clean installation directory
2. default install 1.0.7 
3. default install b2 on top of 1.0.7 without uninstalling 1.0.7 first.
4. update 
Comment on attachment 201625 [details] [diff] [review]
They are directories, not files

I'll sr this for Darin as I believe he is away today. 

I've verified by CVS and by examining my profile directories by hand that these are in deed directories and not files.
Attachment #201625 - Flags: superreview?(darin) → superreview+
deletion of defaults/ profile/
> {972ce4c6-7e08-4474-a285-3208198ce6fd} fixed the problem for me.
Attachment #201625 - Flags: approval1.8rc2?
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #201625 - Flags: approval1.8rc2? → approval1.8rc2+
Flags: blocking1.8rc2? → blocking1.8rc2+
*** Bug 314784 has been marked as a duplicate of this bug. ***
Fixed on 1.8 branch.
Keywords: fixed1.8
*** Bug 314815 has been marked as a duplicate of this bug. ***
I'm stuck on Thunderbird version 1.5 (20051101). The corresponding Thunderbird bug was marked a duplicate of this one. 
I realize this bug is marked as fixed, but at least for me, when the upgrade process failed, it did so silently -- I didn't get any notification that the upgrade process had encountered any errors. Should this issue be a separate bug?
(In reply to comment #46)
> I realize this bug is marked as fixed, but at least for me, when the upgrade
> process failed, it did so silently -- I didn't get any notification that the
> upgrade process had encountered any errors. Should this issue be a separate
> bug?
> 

I was thinking the same thing, as I was given no indication from FF there was a problem. It just simply kept asking me to restart Firefox, and that was about it (not counting my own investigations).

As a workaround for upgrading (with Thunderbird), I had to remove {972ce4c6-7e08-4474-a285-3208198ce6fd} from both $BASE\defaults\profile\extensions\, and $BASE\extensions\.
(In reply to comment #47)
> 
> I was thinking the same thing, as I was given no indication from FF there was a
> problem. It just simply kept asking me to restart Firefox, and that was about
> it (not counting my own investigations).
> 

We have been talking about that problem in the approval meeting, but we're not
seeing a general solution coming up for 1.5.
Thinking more about how to stabilize update is on the TODO list, though. Darin
is reportadly back tomorrow, maybe we'll get a bug on this or some other tracking.
same as comment #31 . thanks for the solution.
*** Bug 314876 has been marked as a duplicate of this bug. ***
Attached image The weird status bar — 
The resolution suggested in this bug worked for me, but when the bug was occuring, I had a weird status bar (see screenshot), no matter what theme I used.  When I deleted the directory and let Firefox update, the message went away.
(In reply to comment #52)

That is bug 314674.
*** Bug 314932 has been marked as a duplicate of this bug. ***
An interesting note... I did not have the extension everyone said was the culprit even installed in my user profile. However, upon further investigation, I found that my administrator account (which was used to install the software) did have it. I don't even see why that profile was affecting mine, but it did. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006
Well ****. I deleted the {972...} extension directory (in the admin account, not my own because there was none) and it still wants to update continuously :(  Any other ideas guys?
This is all about program directory, not about profiles.
ProgDir/defaults/profile, not your profile.
*** Bug 314956 has been marked as a duplicate of this bug. ***
*** Bug 314674 has been marked as a duplicate of this bug. ***
*** Bug 314964 has been marked as a duplicate of this bug. ***
*** Bug 314988 has been marked as a duplicate of this bug. ***
(In reply to comment #61)
> *** Bug 314988 has been marked as a duplicate of this bug. ***
> 
My last-update.log shows the execution fails at:
  EXECUTE REMOVE   defaults/profile/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
  copy_file: failed to open or stat:   -1,defaults/profile/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd},13
  backup_create failed: 6
  ### execution failed

Then backs out and:
  failed: 6
  calling QuitProgressUI

leaves without a notice.

Incidentally, my Win is in a non-standard directory: F:\Windows.  Also F:\Program Files

The install seems to be quite regular before this REMOVE fail.  After the installer backs out, the referred directory does exist, with install.rdf and subdirectory chrome, which is empty.  This seems to be a left over.  Why does the directory REMOVE fail, and why is there an empty subdirectory contained in it?  Did someone forget to remove the chrome sub?  Does that block the parent directory REMOVE?

Seems rather fragile, doesn't it?  And why is this bug marked RESOLVED FIXED?

In reply to comment #62:

Your symptoms are the same as the rest of this bug, hence the duplicate resolution of your report. This bug is marked fixed because a change has been made to the code (attachment 201625 [details] [diff] [review]), preventing this problem from recurring in RC2. 


The workaround for this bug is:
Delete the {972ce4c6-7e08-4474-a285-3208198ce6fd} directory from <firefox_install_dir>\defaults\profile\extensions\

Eg: C:\Program Files\Mozilla Firefox\defaults\profile\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}\
Whiteboard: See comment #63 for workaround
*** Bug 315082 has been marked as a duplicate of this bug. ***
*** Bug 315093 has been marked as a duplicate of this bug. ***
*** Bug 315164 has been marked as a duplicate of this bug. ***
*** Bug 315231 has been marked as a duplicate of this bug. ***
Confirmed that this bug doesn't occur when installing the 20051104 branch nightly over the top of 1.0.7, and then updating on the nightly channel. It's not a test of the updater though, because the nightly installer is cleaning up the offending directory. Same result when installing 1.5 RC1 over 1.0.7, as bug 310010 landed before 1.5rc1.
*** Bug 315386 has been marked as a duplicate of this bug. ***
*** Bug 315516 has been marked as a duplicate of this bug. ***
*** Bug 315537 has been marked as a duplicate of this bug. ***
*** Bug 315847 has been marked as a duplicate of this bug. ***
Now it works properly for updating Firefox 1.5 RC1 to the update of no new name that the auto-update mechanism automatically detected today (1.5 RC1a? -- the Mozilla web page to download Firefox still offers "Firefox 1.5 RC1").
Guys, I got this when moving from RC1 to RC2 - the endless update apply failed loop. Should this normally happen, since the fixed code is in the RC2 and I'm using now the RC1 update code?
*** Bug 316095 has been marked as a duplicate of this bug. ***
*** Bug 315941 has been marked as a duplicate of this bug. ***
*** Bug 316110 has been marked as a duplicate of this bug. ***
Still getting this using windoze 2000
download update
action update 
uabable to update
new version to update
repeat
*** Bug 316952 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
blocking-b2g: --- → 1.3?
Please don't set random flags (blocking-b2g) on bugs which have been fixed 8 years ago.
Please file new bugs for new issues, always.
blocking-b2g: 1.3? → ---
You need to log in before you can comment on or make changes to this bug.