On Jan 9, 2014, at 6:27 AM, Totte Alm wrote: > I'm moving an older but large inhouse application from 10.6/32-bit/GC to > 10.9/64-bit/ARC. > It uses an internal auto update functionally where the app can store itself > into the database when it detects it is a new version, then the other users > will get "update reminders" to download the latest version, which self > updates. > > Now, the tricky part on 10.9 > I move "myself" to trash as theapp-old.app, unzips the fetched zipfile into > /Applications (or where the user put it), all this works. The application is > signed with a dev-id. > Then I use [NSWorkspace defaultWorkspace] launchApplication:pathstring] to > launch the new copy. > > [NSWorkspace defaultWorkspace] launchApplication:pathstring] returns YES > (which means the app is launched or running), but the new instance isn't > started and I get this in the log which sounds very much like "gatekeeper > interference". > 2014-01-09 13:11:33,981 launchservicesd[58]: Application App:"xxxxx" > asn:0x0-563563 pid:2239 refs=7 @ 0x7fb00940b730 tried to be brought forward, > but isn't in fPermittedFrontApps ( ( "LSApplication:0x0-0x564564 pid=2247 > "SecurityAgent"")), so denying. : LASSession.cp #1481 SetFrontApplication() > q=LSSession 100005/0x186a5 queue > 2014-01-09 13:11:33,982 WindowServer[102]: [cps/setfront] Failed setting the > front application to xxxxx, psn 0x0-0x563563, securitySessionID=0x186a5, > err=-13066 > > If I manually (in Finder) launch the application it works fine.
I don't think this has anything to do with Gatekeeper. Gatekeeper only applies to quarantined downloads and downloads are only quarantined by explicit calls to the appropriate API. It's good practice for web browsers, emails programs, and the like to quarantine the things they download, but the system doesn't enforce this. Also, since you can launch it without incident from the Finder, there's no reason to suspect Gatekeeper thinks the app is suspicious. The console messages you're seeing are about an already-running app – it's got a PID, etc. – not being set as the front app. It would still be visible on the screen (and in the Dock and application switcher). It was just denied from being made frontmost. I recommend two things. First, use -[NSWorkspace launchApplicationAtURL:options:configuration:error:] or some other URL-based method, rather than -[NSWorkspace launchApplication:], to launch the app. I don't trust that passing a full path to -launchApplication: will reliably launch that specific copy of the app. Second, use a trampoline program. Quit the original instance of the app before attempting to launch the new one. The first instance would launch the trampoline and quit itself. The trampoline would wait for the first instance to quit and then launch the new app. Waiting for the first instance to quit can be accomplished in a number of ways. I'm partial to having a pipe open between the processes where the first app has the only write end and the trampoline has the read end. When the first app process exits, the kernel will close its file descriptors including the write end of the pipe. The trampoline will then get end-of-file on its read end. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
