300087 - Mac update fetches, but does not apply

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Mike Shaver (:shaver emeritus)]

When I update today (0708) from yesterday's nightly, I get to download the new
build, but after restart it doesn't apply anything (no patching window comes up,
no messages on the console or JS console).  I tried running updater.app by hand
as well, and didn't get anything.

active-update.xml:
<updates xmlns="http://www.mozilla.org/2005/app-update"/>

updates.xml:
<updates xmlns="http://www.mozilla.org/2005/app-update"><update type="minor"
name="Deer Park 1.0+" version="1.0+" extensionVersion="1.0+"
detailsURL="undefined" licenseURL="undefined"
serviceURL="https://aus-staging.mozilla.org:8711/update2/0/Firefox/1.0%2B/2005070707/Darwin_ppc-gcc3/en-US/update.xml"
installDate="1120831182796" statusText="Install Pending"
isCompleteUpdate="false"><patch type="complete"
URL="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-07-07-21-trunk/firefox-1.0+.en-US.mac.mar"
hashFunction="MD5" hashValue="f34d2966c30fb8f6bc51c1a1a9972886" size="8490739"
selected="true" state="pending"/></update></updates>

Not sure if this is just the server being mistaken about there being newer
builds for me, or what, but I thought I'd file it.

Comment 1

[Mike Shaver (:shaver emeritus)]

I'm still seeing this; after I restart, the update archive gets deleted, but I
never get the "updating Firefox" window, and the build is the same old one.

Is there some kind of logging I can turn on?

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Mano tells me that this got fixed two days ago, but I can't find a duplicate bug
tracking that fix. At any rate, as of at least 2005-07-20 builds, this works now.

Comment 3

[Asaf Romano (gone)]

Point is, I'm not aware of any mac-swu fix which was landed in that time frame
(and I was able to reproduce this issue until two days ago or so).

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

I was apparently a little premature in filing this as WORKSFORME :) What I'm
seeing now is that the update applies *once*, and then subsequent updates do not
get applied.

Is active-update.xml supposed to be deleted after the update is applied? If so,
that's the problem, since it's still there after an update.

1. Get a day-before-today-nightly build
2. Check for updates
3. Restart & apply updates
4. Look in Deer Park.app/Contents/MacOS/
5. Check for updates again tomorrow (or modify the app.update.url to fake a
previous build number by switching %BUILD_ID% to "0" and check today!)
6. Restart & apply updates
7. Notice that they're not applied!

You'll see the active-update.xml ... I'll attach the one that was lying around
in mine.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: active-update.xml that was left around after applying updates

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Nominating for 1.8b4 blocker

Comment 7

[Darin Fisher]

I just tried updating from a freshly downloaded 7/28 build to the 7/29 build on
my Mac, and it worked.  However, I also see that active-updates.xml is still in
the application directory after the update.  I also see an active-updates.xml
file under Windows, but its contents are significantly different (just an empty
XML tag).

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #7)
> I just tried updating from a freshly downloaded 7/28 build to the 7/29 build on
> my Mac, and it worked.  However, I also see that active-updates.xml is still in
> the application directory after the update.  I also see an active-updates.xml
> file under Windows, but its contents are significantly different (just an empty
> XML tag).

Hm. I just tried removing active-updates.xml and that didn't seem to help. In
fact, I can't seem to find the .mar file from the second update cycle anywhere
on my HDD.

Comment 9

[Gary Elshaw]

I've been using the auto update feature for the last week. Strangely it has been
working on alternate days. Updates for the 24/7, 26/7 and 28/7 versions of Deer
Park were all fine. 

Comment 10

[Gary Elshaw]

(In reply to comment #9)
> I've been using the auto update feature for the last week. Strangely it has been
> working on alternate days. Updates for the 24/7, 26/7 and 28/7 versions of Deer
> Park were all fine. 

It occurred to me the other day, but i wanted to be sure. My experience seems to
indicate DP can only be updated once. Day one: Download nightly .dmg, Day two:
update it the next day via updates mechanism, Day 3: download via updates
mechanism fails to overwrite.

I'm guessing something is being written somewhere to prevent further updates?
I've also tried scouring my hard drive for any signs of
firefox-1.0+.en-US.mac.mar after a failed update and their doesn't appear to be
any sign. 

OS X 10.4.2 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050730 Firefox/1.0+

Comment 11

[Darin Fisher]

> I've also tried scouring my hard drive for any signs of
> firefox-1.0+.en-US.mac.mar after a failed update and their doesn't appear to be
> any sign. 

The file is actually downloaded to update.mar.

Comment 12

[Darin Fisher]

When I hit this problem today, I noticed that the updates/0/ folder contained a
copy of updater.app.  There was nothing else left in the folder.  When I deleted
the entire updates/ folder, the problem went away, and I was able to update from
the 7/29 build to today's 8/1 build.

Adding this to my bug list.

Comment 13

[Gary Elshaw]

(In reply to comment #12)
> Adding this to my bug list.

Thanks for the tip Darin, i'll keep an eye open for it. I successfully updated this morning after grabbing a 
nightly yesterday. I notice two updater.app's in DeerPark.app. One in DeerPark.app/Contents/MacOS, and 
another in DeerPark.app/Contents/MacOS/updates/0/updater.app.

Is this correct/normal or expected?

Comment 14

[Gary Elshaw]

From the javascript console

"Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
 location: "JS frame ::
file:///Applications/DeerPark.app/Contents/MacOS/components/nsUpdateService.js
:: cleanUpUpdatesDir :: line 318"  data: no]
Source File:
file:///Applications/DeerPark.app/Contents/MacOS/components/nsUpdateService.js
Line: 318"

Line 318 is "updateDir.remove(false);"

OS X 10.4.2 – Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050801 Firefox/1.0+

Comment 15

[Darin Fisher]

Yeah, I think it's having trouble removing updates/0/updater.app/ because it
does not expect that to be a directory.  Under other systems (Linux and
Windows), it is not a directory; it is a simple executable.  The solution is
probably to change nsUpdateService.js to pass |true| to the nsIFile::remove method.

Comment 16

[Darin Fisher]

*** Bug 303024 has been marked as a duplicate of this bug. ***

Comment 17

[Darin Fisher]

Attachment: v1 patch

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 191407 [details] [diff] [review]
v1 patch

r=[e-mail]

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Will this land tonight? I'd love to be able to test it ..

Comment 20

[Darin Fisher]

> Will this land tonight? I'd love to be able to test it ..

If someone will approve the patch, then I will land it.

Comment 21

[Gary Elshaw]

(In reply to comment #20)
> > Will this land tonight? I'd love to be able to test it ..
> 
> If someone will approve the patch, then I will land it.

...bless this patch which we are about to receive, for we are truly grateful.

Comment 22

[Darin Fisher]

fixed-on-trunk