Updating Fire to build .2415 hangs on mounting .dmg

I launched Fire this morning and was notified that a new build was available. It eventually downloaded completely and I told it to initiate the update. When I do that, it just hangs and never gets past mounting the .dmg…I eventually have to Force Quit Fire, and then get prompted again that there’s an update available when I relaunch it.

Ideas?

I should clarify - “hang” in this context does NOT mean that Fire becomes unresponsive…I just mean that the update process never finishes and never progresses past “Mounting RemObjects Fire - 10.0.0.2415.dmg…”

For what it’s worth I manually downloaded the update to .2415 and installed, which bypasses the problem.

Scott,

thanx for letting us know. I’ve seen this reported once before, it’s in my list to get looked at soon. Glad to hear the manual update worked ok as a workaround, and my apologies for the inconvenience :(.

It’s something to do with the download itself. If I do the download manually, in the right place, and Fire sees it there, it updates itself just fine.

Yeah. I’m using the official NSURLSession background downloads API, and it somehow f’s the file up :(.

And yet comparing the download I do manually with the Fire one, says they are identical. I guess it must be some permission or something such that it’s not seen as the same but the OS when you come to open it.

Possibly. can you manually mount the one downloads by Fire? or does that to hang/err? what do the file rights say?

I’ll try it and report back, it’s been a while since I let Fire do it itself so can’t recall exactly.

Fire’s download:
DMG Opens fine, can see Fire in it but if you try and open it:


I can copy it somewhere else (obviously not over the old Fire) and get the same thing when trying to open it.
I managed to trap this in terminal, when trying to open it, which may help:

Non-fatal error enumerating at <private>, continuing: Error Domain=NSCocoaErrorDomain Code=260 "The file “PlugIns” couldn’t be opened because there is no such file." UserInfo={NSURL=PlugIns/ -- file:///Users/Jeremy/Desktop/Fire.app/Contents/, NSFilePath=/Users/Jeremy/Desktop/Fire.app/Contents/PlugIns, NSUnderlyingError=0x7fa02f64ab50 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

process there was lsd (LaunchServices)

and

exec of /Users/Jeremy/Desktop/Fire.app/Contents/MacOS/Fire denied since it was quarantined by and created without user consent, qtn-flags was 0x00000186

Process was kernel.

and

spawn_via_launchd() failed, errno=1 label=[0x0-0x2c52c5].com.remobjects.fire path=/Volumes/Fire 10.0.0.2415/Fire.app/Contents/MacOS/Fire flags=1

Process was Finder.

I can confirm there is no plugins folder there, but then there isn’t one in the other one and console doesn’t give this message

The file info (Fire’s is the one on the right):


That’s for the DMG files. The Fire app itself has the same info on both (permissions as per top left one above). I did try adjusting the permissions on the Fire one for everyone just out of interest, but of course it didn’t change anything.

plot, thickened. I’m sure this is what the underlying problem is. Question is why is it quarantained differently.

if you run sudo spctl disable, can you then open it fine? (run sudo spctl enable again afterwards; this essentially disables Gatekeeper).

The same “can’t be opened error”. Same console log. (it was --disable/enable btw).

Maybe a missing entitlement/permission in Fire?

Scott

Doubtful, since the file also doesnt open outside of Fire. but I’ll check if there’s requirements for Downloads… Fire isn’t Sandboxed though…

For what it’s worth updating from 10.0.0.2415 to 10.0.0.2419 had the same behavior. After downloading the disk image, the Fire UI displays the “mounting…” window that never goes away. diskutil list, Finder, and Disk Utility show the volume mounted. Dragging the Fire.app from the volume into Applications folder works fine, launching the copied file does not. Downloading a fresh copy of Fire directly from the website and copy/overwrite the bad copy yields a working application.

Yeah, I’m afraid I have noire gotten around to reproducing.fixing this yet, but I will try for next week (which would mean it would be fixed for upgrading from the build that has the fix to newer ones, of course).

It seems that there are two separate problems here

(a) somehow the .dmg downloaded by the background downloader gets quarantined badly, and thus it doesn’t mount correctly (manually or by Fire)

(b) somehow Fire does nit detect this failure properly, and just keeps failing

I would appreciate if one of you could

(1) give men the output of both xattr /path/to/Fire.dmg and spctl -a /path/to/Fire.dmg and (2) check if running xattr -r -d com.apple.quarantine /path/to/Fire.dmg fixes the problem the same way manually downloading does.

thanx!
marc

Where does the Fire updater store the downloaded image to? If it’s still there I’ll grab what you’re after, but since I already manually updated Fire I can’t reproduce it from scratch.

~/Downloads, IIRC.

Hello Marc,
I have tested it with 2415:


The mount in Fire will not finish, in the finder it is visible at this time.

Results from Terminal:

xattr /Users/Westermann/Downloads/RemObjects\ Fire\ -\ 10.0.0.2419.dmg
com.apple.diskimages.fsc
com.apple.diskimages.recentcksum
com.apple.quarantine

spctl -a /Users/Westermann/Downloads/RemObjects\ Fire\ -\ 10.0.0.2419.dmg 
/Users/Westermann/Downloads/RemObjects Fire - 10.0.0.2419.dmg: File created by an AppSandbox, exec/open not allowed

after execute :

xattr -r -d com.apple.quarantine /Users/Westermann/Downloads/RemObjects\ Fire\ -\ 10.0.0.2419.dmg

it can be opened and installed