Closed
Bug 300087
Opened 20 years ago
Closed 19 years ago
Mac update fetches, but does not apply
Categories
(Toolkit :: Application Update, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.8final
People
(Reporter: shaver, Assigned: darin.moz)
References
Details
(Keywords: verified1.8)
Attachments
(2 files)
(deleted),
text/xml
|
Details | |
(deleted),
patch
|
bugs
:
review+
chase
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•20 years ago
|
||
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•20 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Comment 3•20 years ago
|
||
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•20 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 5•20 years ago
|
||
Assignee | ||
Comment 7•19 years ago
|
||
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).
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Comment 8•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
(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+
Assignee | ||
Comment 11•19 years ago
|
||
> 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.
Assignee | ||
Comment 12•19 years ago
|
||
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.
Assignee: nobody → darin
Status: REOPENED → NEW
Target Milestone: --- → Firefox1.1
Comment 13•19 years ago
|
||
(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•19 years ago
|
||
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+
Assignee | ||
Comment 15•19 years ago
|
||
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.
Assignee | ||
Comment 16•19 years ago
|
||
*** Bug 303024 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 17•19 years ago
|
||
Attachment #191407 -
Flags: review?(bugs)
Comment 18•19 years ago
|
||
Attachment #191407 -
Flags: review?(bugs) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #191407 -
Flags: approval1.8b4?
Comment 19•19 years ago
|
||
Will this land tonight? I'd love to be able to test it ..
Assignee | ||
Comment 20•19 years ago
|
||
> 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•19 years ago
|
||
(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.
Updated•19 years ago
|
Attachment #191407 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 22•19 years ago
|
||
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
Keywords: fixed1.8 → verified1.8
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•