313623 - updater does not remove updates/0 directory upon completion of update

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Chase Phillips]

After I removed the update for 2005102322, I installed 2005102105 and updated to 2005102400.  The app started as expected and the build ID in master.ini showed as 2005102400.  From here, I attempted to update again, expecting the 2005102404 update to appear.  The result instead was an error "The integrity of the update could not be verified (Contact your Administrator)".  This error appeared before the app showed any progress in downloading the update, making me suspicious that it downloaded anything at all.  The only choice given to me is to click the "Finish" button (so I didn't fall back to trying the complete update).

I looked in updates/0 and found that the old update from 2005102322 to 2005102400 was still there.  That was also unexpected.

The app update URL my client should be using for this update is https://aus2.mozilla.org/update/1/Firefox/1.5/2005102400/WINNT_x86-msvc/en-US/nightly/update.xml.  I downloaded both patches and ran sha1sum and verified the checksums are correct.  I also checked that the listed size in the update.xml matched the filesize of the downloaded updates.

Next, I will shut down Firefox, remove updates/0, and attempt to update.

Comment 1

[Scott MacGregor]

The same thing happens to me when updating Thunderbird. In my case I got updated to th 10/22 build and further attemps to update give me the same error you are seeing "the integrity of the update could not be verified..."

Comment 2

[Chase Phillips]

(In reply to comment #0)
> Next, I will shut down Firefox, remove updates/0, and attempt to update.

After removing updates/0 I was able to update to the next version, 2005102404.  After updating, I noticed that the 2005102404 Firefox was not auto-launched for me.  I also noticed that updates/0 continued to be full of the previous update files.

Maybe the updater isn't finishing up after the update is complete (removing the updates/0 directory, starting the app)?

Comment 3

[Chase Phillips]

(In reply to comment #0)
> I looked in updates/0 and found that the old update from 2005102322 to
> 2005102400 was still there.  That was also unexpected.

I meant to say that the old update from 2005102105 to 2005102400 was still in updates/0.  Sorry for any confusion.

Comment 4

[Chase Phillips]

(In reply to comment #1)
> The same thing happens to me when updating Thunderbird. In my case I got
> updated to th 10/22 build and further attemps to update give me the same error
> you are seeing "the integrity of the update could not be verified..."

Since the updater used is from the source build, then the problem is likely in the 20051021* builds and regressed sometime between 20051020* and 20051021*.  It doesn't manifest until the next time the update system is used (which in Firefox's cases is 20051024* due to build issues and in Thunderbird's is 20051022*).

Scott what Thunderbird build ID were you updating from?

Comment 5

[Ria Klaassen (not reading all bugmail)]

Same error twice. After removing the updates folder and the two xml files it updated it to 1.8b5_2005102406. Did not auto launch.

Comment 6

[Chase Phillips]

I feel fairly confident that the problem is that the updater isn't removing the updates/0 directory at completion of the update.  Updating summary to reflect.  We'll revert if it turns out the problem is somewhere else.

blocking1.8rc1?

Comment 7

[Scott MacGregor]

(In reply to comment #4)
> Scott what Thunderbird build ID were you updating from?
> 

2005102208 once I update to that build ID, I get the integrity failure error.

Comment 8

[Scott MacGregor]

yeah this is going to be a blocker :)

Comment 9

[Scott MacGregor]

I wonder if this is fall out from Bug 312360 which went in on 10/21.

Chase, I had an updated 10/21 build with a build ID of: 2005102106

was then updated to 2005102208 and cannot upgrade further.

Comment 10

[Ria Klaassen (not reading all bugmail)]

Updating Thunderbird:
1.8b5_2005102106 to 1.8b5_2005102208: no problem.
1.8b5_2005102208 to 1.8b5_2005102308: error.
1.8b5_2005102308 to 1.8b5_2005102406: error.

Comment 11

[Darin Fisher]

Sounds like we need to get someone on this... I'll take a look as soon as possible.

Comment 12

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Bug 313240 also went in about the same time...

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

Following up on Chase's request for confirmation in bug 313506, I also see that the update from 2005102105 leaves the contents of the updates/0 directory which prevents the next update. 

Isn't the timing for bug 312360 and bug 313240 off by a day ? If the checkin was 2005-10-21 11:31 PDT, then that code would have been in the 20051022 nightly and would first show up in 20051024 for testing. There was a change on 20051020, which was bug 311288 and might have affected the cleanup after the update.

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

The second half of my previous comment is wrong. Changes to mozilla/ toolkit/ mozapps/ update/ src/ nsUpdateService.js.in between the creation of the 20051021 and 20051024 nightlies do matter, since it is responsible for cleaning up the updater's leftovers on the restart - 
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#332

Update changes in the last week:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=mozilla%2Ftoolkit%2Fxre%2Cmozilla%2Ftoolkit%2Fmozapps%2Fupdate&filetype=match&whotype=match&sortby=Date&hours=2&date=week&mindate=1130176680&cvsroot=%2Fcvsroot

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

I think I've managed to narrow this regression to a single bug. By manually updating the 2005102105 zip build (http://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file) I could remove the changes to nsUpdateService.js before restarting Firefox. 

Bug 313240 was the culprit - backing this patch out results in an empty updates/0 directory. There doesn't seem to be a last-update.log left either, but that was also a problem in the 20051020 build and must be a separate regression.

Comment 16

[Nick Thomas [:nthomas] (UTC+12)]

Ben T, this could well be a problem with this.canUpdate not being defined on restart. Can you confirm and come up with a fix ?

Comment 17

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Yeah, this was definitely caused by the fix for bug 313240. I'm on it.

Comment 18

[Chase Phillips]

(In reply to comment #14)
> The second half of my previous comment is wrong. Changes to mozilla/ toolkit/
> mozapps/ update/ src/ nsUpdateService.js.in between the creation of the
> 20051021 and 20051024 nightlies do matter, since it is responsible for cleaning
> up the updater's leftovers on the restart - 
> http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#332

Surprise!  And good catch! :)

Comment 19

[Darin Fisher]

It looks like it is the early return in cleanUpUpdatesDir that is causing the problem.  For some reason, |this.canUpdate| is returning false when cleanUpUpdatesDir is called from _postUpdateProcessing.

Doh!  And, the reason for the failure is simple.  cleanUpUpdatesDir is a global function, and so |this.canUpdate| is undefined! :-(

Comment 20

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch

Ok, so this should fix everything. Nick was right, 'this.canUpdate' is undefined! This fix takes care of the case where we lack write/delete permissions and fixes this bug.

Comment 21

[Darin Fisher]

Comment on attachment 200669 [details] [diff] [review]
patch

Yup, looks good.

Comment 22

[Darin Fisher]

fixed-on-trunk

Comment 23

[Darin Fisher]

fixed1.8