On May 10, 2013, at 07:12 , Jerry Krinock <je...@ieee.org> wrote: > I think that it would help to have a higher-level understanding of the > problem. How about this… > > You have a sandboxed app in which the user has somehow opened a document > outside your sandbox (because the user navigated to it in an Open dialog?). > […]
> Have I stated this correctly? I don't think so. The *user* doesn't see files as being in or out of a sandbox. After all, the user isn't sandboxed -- your app is. By and large, *all* documents are outside an app's sandbox. Use of the Open dialog, or resolving a security-scoped bookmark, grants the app access to a document *as if* if it was inside the sandbox, but the document isn't moved in any way to get this access. An app wanting to migrate a document (including, say, a word processor converting an older document format into a newer one, or converting a format it only knows how to read into one it knows how to write) is eventually going to have to create a new file, and a sandboxed app is therefore going to have to ask for permission via the Save dialog. [I'm talking here of a migration that preserves the original file beside the migrated one.] In the case of Core Data, this means that a sandboxed app cannot use automatic migration, but must migrate manually. On May 8, 2013, at 21:20 , Jim McGowan <jim_mcgo...@mac.com> wrote: > to hijack the migration process to display a save dialogue to get user > permission for the destination URL […] creates a confusing user experience > (opening a document shouldn't immediately present a save dialogue) Yet, failing to get permission via a save dialog would defeat sandbox security. Malware invading your app would be able to hijack the migration process to create any file it wants, anywhere on the user's system. It's not clear that interacting with the user must be confusing. You could start with an alert that explains that the document format needs updating, offering a Save button that leads to the Save dialog. Annoying, perhaps, but not necessarily confusing. There are a couple of other approaches that might be preferable to you. The question is how well (or if) they work with NSPersistentDocument: 1. Use post-Lion "autosave elsewhere" to migrate the Core Data store into a new untitled document in a temporary location. This would defer the Save dialog until the document window closes. 2. Put your Core Data store inside a file package. Then do the migration within the package. However, you likely wouldn't be able to use NSPersistentDocument any more, since it doesn't sound like it supports packages directly. 3. Migrate your Core Data store to a temporary file, then move the migrated file back to the original location, replacing the pre-migration file. Presumably, this is the same approach that NSDocument Save takes, but you'd need to implement it yourself, since NSPersistentDocument doesn't (AFAIK) do this. The replacement needs to be safely done (using the file system's "exchange objects" API), otherwise a crash or failure during replacement would effectively destroy the document. _______________________________________________ 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
