601701 - Automatic updates get stalled when installed version is newer than a downloaded update restored using Windows system restore.

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Daniel Morante]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 FirePHP/0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

When a downloaded update is older than the currently installed version, new updates are no longer downloaded and the currently downloaded update gets "stuck".

Reproducible: Always

Steps to Reproduce:
I discovered this when I recently recovered from a Windows crash.  My copy of Thunderbird had a downloaded update (version 3.1.1) waiting to be applied.

After reloading Windows and installing the latest copy of Mozilla Thunderbird (3.1.2 at the time), I restored my user profile directory.  Obviously, this included the Mozilla Application Data and Local Settings folders.

Clearly, this is not the type of thing someone will do on purpose, but as shown above it can happen and can cause problems.  So the steps to manually reproduce are (I think):

1. Download an update (for example 3.1.1)
2. Do not apply update to current version (example: 3.1)
3. Wait until new version (example: 3.1.2) is released
4. Backup and remove your Thunderbird application data and local settings directory
5. Download and Install new version from Mozilla website (example: 3.1.2)
6. Restore application data
7. Launch Thunderbird
Actual Results:  
Thunderbird still wants to apply the 3.1.1 update, when trying to apply the update to the 3.1.2 version, the program restarts and the update is still on 3.1.1.

No new updates are downloaded and the version remains on 3.1.2

Expected Results:  
Thunderbird should delete the old update

The same might happen on Firefox, but I have not tested.  Might be related to bug #575124

Comment 1

[Robert Strong (they/them - no direct email)]

Was there an update.version file in the updates/0 directory that was restored? I suspect not but it would be great if you could verify. That file prevents this for the typical cases.

Comment 2

[Daniel Morante]

The updates directory currently contains:

 Directory of C:\Documents and Settings\Danny\Local Settings\Application Data\Th
underbird\Mozilla Thunderbird\updates

09/03/2010  04:24 PM    <DIR>          .
09/03/2010  04:24 PM    <DIR>          ..
06/18/2010  02:47 PM            78,015 backup-update.log
06/26/2010  12:47 PM           107,128 last-update.log
               2 File(s)        185,143 bytes

I do not see a "0" directory anywhere.  Were would that be located.

Comment 3

[Robert Strong (they/them - no direct email)]

Is it still stuck? If not, what steps did you perform to recover?

Comment 4

[Daniel Morante]

Still stuck on version 3.1.2 wanting to apply version 3.1.1.

I haven't done anything to try and recover.

Comment 5

[Robert Strong (they/them - no direct email)]

Please attach the active-update.xml located in
:\Documents and Settings\Danny\Local Settings\Application Data\Thunderbird\Mozilla Thunderbird\

Comment 6

[Daniel Morante]

Attachment: The active-update.xml file as requested

Comment 7

[Robert Strong (they/them - no direct email)]

Please open about:config (e.g. Tools -> Options -> Advanced -> General -> Config Editor, click the "I'll be careful, I Promise!" button if it is displayed, right click and select New -> Boolean. For the name type app.update.log and for the value select True. Restart Thunderbird and open the Error Console. Copy any messages that start with AUS: and paste them into this bug. Thanks!

Comment 8

[Daniel Morante]

AUS:SVC gCanCheckForUpdates - able to check for updates

Comment 9

[Brett Wilson]

I'm seeing this same problem, but I think it happened without a windows restore. My update to 3.1.5 kept failing, so I downloaded 3.1.5 and updated manually. I had to repeat this for 3.1.6, and Thunderbird still wants to update to 3.1.5. If I let Thunderbird try to update itself, it restarts and nothing changes.

Comment 10

[Robert Strong (they/them - no direct email)]

Brett, please file a separate bug

Comment 11

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

This also happened to dougt's Linux system though I'm at a loss how this would have happened on Linux. Definitely something that would be nice to get for Firefox 4.0

Comment 12

[Robert Strong (they/them - no direct email)]

In dougt's case what I think happened is there was a staged update and he manually upgraded before applying. On startup the old version was found and deleted but the active-update.xml was not deleted. This left him in a state where he could not check for updates.

Comment 13

[Dave Townsend [:mossop]]

Sounds like  few ways this could happen and it hoses our ability to deliver updates so we should block on this.

Comment 14

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/46446fa861b5

This also affects 1.9.1 and 1.9.2

Comment 15

[LegNeato]

Denying blocking but marking as wanted for branches.

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 503416 [details] [diff] [review]
patch rev1

Approved for 1.9.2.15 and 1.9.1.18, a=dveditz for release-drivers

Comment 17

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-1.9.2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e170a8a1662b

I'll push to mozilla-1.9.1 after my 1.9.1 build finishes.

Comment 18

[Robert Strong (they/them - no direct email)]

Attachment: 1.9.1 patch

Had to change the test a bit for 1.9.1

Comment 19

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5c0df5e74962

Comment 20

[Daniel Veditz [:dveditz]]

The "3.6.15" we're releasing today does not fix this bug, the release containing this bug fix has been renamed to "3.6.16" and the bugzilla flags will be updated to reflect that soon. Today's release is a re-release of 3.6.14 plus a fix for a bug that prevented many Java applets from starting up.