Re: document inexplicably becomes locked and fails to save under sandboxing
Re: document inexplicably becomes locked and fails to save under sandboxing
- Subject: Re: document inexplicably becomes locked and fails to save under sandboxing
- From: Martin Wierschin <email@hidden>
- Date: Wed, 11 Jun 2014 11:58:19 -0700
Thank you for your thoughts Mr. SevenBits!
> What I believe your problem to be is what you are doing here is you are getting access to your file, opening it, and then immediately revoking that access with the subsequent stopAccessingSecurityScopedResource call. By the time the document has been opened, access to the opened file has been revoked, and the "Locked" text is displayed because you no longer have permission to modify the file.
I think that's very likely to be the cause of the problem. However, I would have expected NSDocument/NSDocumentController to take this kind of situation into account and maintain access to the URL for as long as it needs. After all, it's not a problem when you take a URL from an NSOpenPanel and open a document. In both cases NSDocumentController only has access to the file at the time you create the document. Why doesn't sandboxing magic occur here, but does occur when using NSOpenPanel?
I also tried a more liberal approach: before the document is opened call startAccessingSecurityScopedResource, and then only call stopAccessingSecurityScopedResource on document dealloc. Even that does not prevent the document from becoming locked and saving to fail.
So it seems there's some aspect to this problem that's not just a matter of keeping that security-scoped URL access open.
> I can somewhat workaround the problem by overriding -[NSDocument performSynchronousFileAccessUsingBlock:], wrapping super's implementation with -[NSURL startAccessingSecurityScopedResource] for the relevant URL.
>
> One gotcha: every call to startAccessingSecurityScopedResource *must* be accompanied by a call to stopAccessingSecurityScopedResource. Under this approach, this requirement will not be met, unless you are doing something else that you are not telling us about?
I wasn't exactly clear in my original message. When I said "wrapping" I meant that I call both the start and stop methods around the invocation to super. Explicitly that looks like this:
- (void) performSynchronousFileAccessUsingBlock:(void(^)())block
{
NSURL* resolvedURL = [self fileURLResolvedFromSavedBookmarkData];
[resolvedURL startAccessingSecurityScopedResource];
[super performSynchronousFileAccessUsingBlock:block];
[resolvedURL stopAccessingSecurityScopedResource];
}
So my calls to security-scoped access are always balanced.
> Is having your own recent documents support really necessary?
Our users find it very helpful. And it's not just recent document support, but also user-created document lists.
The merits of this particular feature aside, I would expect this to work. It seems an oversight that you can't use bookmark data to reopen documents. I suppose I'll file a radar, though I'll still need to workaround this somehow.
Thanks again for your reply,
~Martin Wierschin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden