On Jun 20, 2013, at 13:07 , Karl Moskowski <kmoskow...@me.com> wrote:
> In fact, I think that will almost always be the case, so the > link-to-an-external asset approach may not be practical. Anyway, would that > approach work with Sandbox restrictions? What about potential iCloud sync in > the future (forgetting for a moment the issues of file size)? It's not an external asset in this case. When you create the clone by hard linking, there are two independent files sharing the same disk storage. The clone file is "in" the document package normally. NSDocument already does hard-linking for files within a package which (according to the wrapper you return) haven't changed since the last save, assuming the file system supports it, so the mechanism is already compatible with sandboxing and iCloud. My point was, though, sort of the opposite. In your document save, you will necessarily need a mechanism to transfer the asset from an existing document package to a new document package. The "problem" of transferring an asset in a temp file to a package isn't really an additional burden, since it can likely use the same mechanism. If you haven't considered the normal save behavior (in the situation of a destination different from the source), then your save strategy is already broken, and you aren't ready to think about the creation behavior. _______________________________________________ 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
