On Jun 20, 2013, at 4:30 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> On Jun 20, 2013, at 4:07 PM, 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. So, when importing the asset upon new document creation, actually import it to a temp directory, then upon save of the document, hard-link to the temp asset (via NSFileManager methods)? How would you delete the original hard link from the temp directory? Just delete the temp directory itself non-recursively? (I couldn’t find any unlinking APIs.) > 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. In modern document-based apps, this would be via the “Duplicate” menu, right? > 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 behaviour. —Karl.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
