We are working on a sandboxed application that keeps track of a large number of files through security scoped URLs. To access the files we carfully balance our calls to startAccessingSecurityScopedResource / stopAccessingSecurityScopedResource:
[url startAccessingSecurityScopedResource] /* do some work */ [url stopAccessingSecurityScopedResource] All was fine until we needed to start accessing the files from multiple threads simultaneously. According to the documentation: "When you call the stopAccessingSecurityScopedResource method, you immediately lose access to the resource in question (even if you have previously called startAccessingSecurityScopedResource more than once)." Thus, as soon as 1 thread executes its 'stopAccessingSecurityScopedResource', all access in other threaded code blocks is lost. It seems that we must design our own bookkeeping around security scoped urls, make sure we don't manage resource access directly in our frameworks, and hope no 3rd party frameworks call stopAccessingSecurityScopedResource behind our backs. We find this API design disappointing (to say the least), it's as if we need to call retain / release *and also* manage the retain count ourselves... Sandboxing is a good idea in theory, but the implementation has been kicking sand (.) in our faces for a while now. Did we miss some hidden feature? Did anyone design a re-usable solution for accessing security scoped resources from multiple threads? We'd be grateful for any ideas! patrick -- Patrick Machielse Hieper Software http://www.hieper.nl [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
