On Wed, Jun 11, 2014 at 1:18 AM, Martin Wierschin <mar...@nisus.com> wrote:
> Hello everyone, > > I'm sandboxing an NSDocument based application for OS X. In addition to > Apple's standard Open Recent menu, this app also provides the user a few > ways to reopen commonly used documents. To make that work under sandboxing, > I capture a security-scoped bookmark for each such document. Then later, > when the users wants to reopen the file, I resolve that bookmark data back > to a URL. The code is something like: > > NSData* bookmark = XXLoadDocumentBookmarkData(); > NSURLBookmarkResolutionOptions ops = > NSURLBookmarkResolutionWithSecurityScope; > NSURL* url = [NSURL URLByResolvingBookmarkData:bookmark > options:ops relativeToURL:nil bookmarkDataIsStale:NULL error:NULL]; > > [url startAccessingSecurityScopedResource]; > NSDocument* doc = [[NSDocumentController sharedDocumentController] > openDocumentWithContentsOfURL:url display:YES error:NULL]; > [url stopAccessingSecurityScopedResource]; > > Anyways, that code works just fine: the document is reopened with proper > read/write access. > > The problem is that after some period of time, the reopened documents > become locked and saving fails. Both autosave and manual save operations > fail with the error: "you don’t own the file and don't have permission to > write to it". In the document's titlebar the suffix "— Locked" is shown, > and Cocoa prevents me from unlocking the document using the popup options. > The issue never occurs immediately, only after some successful saves and > perhaps a few minutes have passed. I have discerned no pattern to when or > what triggers the locking. > > Does anyone have any idea what's going wrong? Why is sandbox access for > these documents being cut off while they remain open? > I will admit that I am not super experienced in this area, but here is my guess. If anyone knows more than I do, feel free to shoot me down on this. When the user normally opens a file, Powerbox (the framework in OS X to manage the sandbox, among other things) grants the application full read/write access once it is opened. 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 can somewhat workaround the problem by overriding -[NSDocument > performSynchronousFileAccessUsingBlock:], wrapping super's implementation > with -[NSURL startAccessingSecurityScopedResource] for the relevant URL. > However, that feels like a hack and makes me very nervous that other things > could be broken. Also, while that restores successful saving, it doesn't > prevent "— Locked" from appearing in the document's titlebar. > 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? Is having your own recent documents support really necessary? The system already includes a menu for it, and in this post-sandboxing world features like this are difficult to do unless your app mandates that documents be saved within its container. > > Thank you for any ideas or help! > > Best, > 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/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
