Closed Bug 313623 Opened 18 years ago Closed 18 years ago
updater does not remove updates/0 directory upon completion of update
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.
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..."
(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)?
(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.
(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?
Same error twice. After removing the updates folder and the two xml files it updated it to 1.8b5_2005102406. Did not auto launch.
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?
Summary: Unable to update from 2005102400 to 2005102404 → updater does not remove updates/0 directory upon completion of update
(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.
yeah this is going to be a blocker :)
Flags: blocking1.8rc1? → blocking1.8rc1+
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.
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.
Sounds like we need to get someone on this... I'll take a look as soon as possible.
Assignee: nobody → darin
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox1.5rc1
Bug 313240 also went in about the same time...
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.
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
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.
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 ?
Yeah, this was definitely caused by the fix for bug 313240. I'm on it.
(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! :)
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! :-(
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.
Attachment #200669 - Flags: review?(darin)
Comment on attachment 200669 [details] [diff] [review] patch Yup, looks good.
Attachment #200669 - Flags: review?(darin) → review+
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Attachment #200669 - Flags: approval1.8rc1? → approval1.8rc1+
You need to log in before you can comment on or make changes to this bug.