On Aug 3, 2016, at 20:49 , maximilian.schm...@mto.io wrote: > > But when working in a team on a professional level (like I have for many > years), when the document is copied around many times from Mac to Mac, to and > from a shared server, the asset-management has to be as simple, transparent > and bulletproof as possible.
> I force an auto save onto the duplicated document (which is a copy of the old > one without the audio files) and then copy all the audio files from the > original into the auto save. When the user then saves the duplicate, I copy > the files from the autosave to the new user-defined destination. The only > problem right now is intercepting the function where the app automatically > deletes the autosaves so can safely copy before that happens. Taking the second part of this first, it’s likely that there’s NO safe mechanism for you to do this manually using the document architecture, because there are no atomic file system operations at the level you’re talking about. Still, you might find something that’s safe enough. If this is for professional-level users who have sufficiently capable Macs (that is, at least a fusion drive if not a SSD, and fast networking everywhere) then I think you can safely ignore the file size and performance aspects of your problem, and your everything-in-the-document-package approach should work well without hacking up NSDocument and NSDocumentController. > Is it possible for the NSDocument to know about the audio files in it’s > package folder and handle them like they belong to it without wholly > representing them in the model? Or can CoreData solve this? I think, however, > that storing the audio data in anything other than actual audio files will > massively complicate things with CoreAudio. I went back to your original question, and read it a bit more carefully. The answer to this is “Yes!”, I think. When your NSDocument loading override is handed a file wrapper, you do not need to represent the audio files in your data model, nor do they need to be read into memory at all, unless you choose to do so. Just leave the audio file sub-wrappers alone, and keep the uber-wrapper around until save time. (What I usually do is delete the sub-wrappers for files that *are* changing, as edits are made. At save time, the absence of a file wrapper tells me I need to write out a new file and create its new sub-wrapper.) When you take that approach, the files with the untouched sub-wrappers should NOT need to be copied by the save**. Instead they are (atomically!) transferred to the new document package version representing the saved document. Isn’t that what you’re trying to achieve? ** Provided you are saving to a local HFS+ file system. Network disks and other file systems may not support this and require re-copying of the unchanged files. _______________________________________________ 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
