> Certainly I don't want to attempt to start and stop access for the search dir
> every time the browser asks for an item's imageRepresentation. I'm guessing
> I'd run into race states there if multiple items are queried at once.
Yes, getting security-scoped URL access started and stopped in the right places
can be a real pain. It’s even more of a pain because NSURL doesn’t do any
reference counting for you. One call to stopAccessingSecurityScopedResource
closes access for all of your code, regardless of how many times access has
been started/nested.
Even worse is that closing one NSURL’s access can close out another NSURL’s
access. For example, consider that you have two NSURL instances that point to
the same file:
NSURL<0x620001676100>:
file:///path/to/file.ext?applesecurityscope=343739...
NSURL<0x61000046c000>:
file:///path/to/file.ext?applesecurityscope=623338…
If you stop access on <0x620001676100> you will also have closed any access
started for <0x61000046c000>! This can be a real headache if your app and its
frameworks each handle their own access. Your app can incorrectly close access
needed by a framework, and vice versa.
Considering Apple’s warnings that using this API correctly is important, they
sure make it difficult. If you use NSURL, security-scoping, and bookmark data
in multiple places in your app, I recommend wrapping it with your own reference
counting API immediately. I filed an enhancement request that this should
already be handled by Apple automatically as rdar://17966481 <rdar://17966481>
> That leaves me with leaving the access open while the app is running, until a
> new searchDir is chosen. That seems to go against Apple's suggestion.
If you only have this one folder in your app where you need to use
security-scoped URL access, you’re probably okay running against Apple’s
guidelines. If I understand the recommendation properly, it’s best practice to
stop access because it’s a limited resource: like file descriptors, your
process only has a certain number. But if you only have this one folder you’re
not going to run out, nor do much to “leak kernel resources”.
~Martin Wierschin
_______________________________________________
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
