9 jan 2014 kl. 17:26 skrev Ken Thomases <k...@codeweavers.com>: > 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.
This looks like a good solution. The reason for [NSWorkspace launchApplication:], is that this is they way it has been working since 10.4-ish. Thanks / Totte > > 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
