On Sep 6, 2016, at 22:44 , Graham Cox <graham....@bigpond.com> wrote:
>
> I still get the console messages:
>
> 2016-09-07 15:34:53.684 MyApp[9226:1630740] CFStringRef
> __CFPasteboardIssueSandboxExtensionForPath(CFStringRef) : sandbox extension
> creation failed: client lacks entitlements? for path:
> [/Users/grahamcox/Desktop/Exports/Snorkel0001-22.jpg]
> 2016-09-07 15:34:53.685 MyApp[9226:1630740] CFDataRef
> __CFPasteboardCreateSandboxExtensionDataFromCFData(CFDataRef) : failed to
> obtain sandbox extension data for url
> [file:///Users/grahamcox/Desktop/Exports/Snorkel0001-22.jpg]
> <file:///Users/grahamcox/Desktop/Exports/Snorkel0001-22.jpg]>
>
> These seem to be benign, but I would like to know where they’re coming from
> and why.
I’ve never seen these before, and I wouldn’t dismiss them as benign.
One thing: you previously referred to the
com.apple.security.files.bookmarks.app-scope entitlement. I don’t believe I’ve
ever needed to specify this, and in a recently-created sandboxed macOS target,
Xcode provides no UI for turning it on. You could try removing it from your
entitlements file.
Otherwise, I’d suggest a bug report.
> The other thing is this. According to docs, if ‘stale’ returns YES when
> resolving the bookmark data, then you should recreate the bookmark data from
> the URL that was returned. On the face of it, this doesn’t seem to be
> different from recreating it anyway, though I can certainly imagine that it’s
> a special case, given the weird nature of sandboxing.
I believe security trumps re-creation. That is, if the bookmark is stale, then
you’ll have to get a “fresh” URL via NSOpen/SavePanel in order to replace the
bookmark data. Only non-security-scoped bookmarks can be refreshed by
recreating the bookmark from the reconstituted URL.
Of course, you’re not obligated to refresh the bookmark if it’s merely stale.
OTOH, it may be that security-scoped bookmarks are never reported as stale.
> Also, when using the -start… and -stop… methods to access resources, should
> the -stop method only be used if the start method returned YES, or used
> whatever? Docs aren’t clear.
According to:
developer.apple.com/library/prerelease/content/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW16
> "Calls to start and stop access are not nested. When you call the
> stopAccessingSecurityScopedResource method, you immediately lose access to
> the resource. If you call this method on a URL whose referenced resource you
> do not have access to, nothing happens.”
I actually ran into this situation a couple of days ago. I ended up adding a
transient “isSecurityStarted” Boolean property to the class that was holding
the security-scoped URL, so that I could call “stop…” only when I had called
“start…”, if I was about to discard the URL for any reason.
_______________________________________________
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
