On Thu, Jan 9, 2014 at 11:26 AM, Ken Thomases <k...@codeweavers.com> wrote: > 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.
Yes, when you download a program from an application like Safari, it sets the "quarantine bit" on the file. This is done by programs like Safari, Mail, etc., or programs that are downloaded in some way from the web. If your application does it, then the system doesn't enforce it. It has to do with application, not necessarily system, policy. I believe that that's how it works, but correct me if I'm wrong. > > 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/sevenbitstech%40gmail.com > > This email sent to sevenbitst...@gmail.com _______________________________________________ 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
