> On Aug 4, 2016, at 12:04 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote > > 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. >
Wow! I gave it a shot and it's working! I did have FileWrappers created for each audiofile but I created them new each time the fileWrapper(ofType:) function was called. Maybe that was the problem? To suit my app, I now create an unmapped FileWrapper each time an audio file is imported and hold on to all of them in an array. This array then get's put in the main FileWrapper in my fileWrapper(ofType:) function. Now, it wouldn't move the files when duplicating the document. But: Copying the FileWrappers over from document to document in the NSDocumentController's duplicateDocument(withContentsOf:copying:displayName:) function solved that, too. Maybe stuff will blow up on me this way, so more testing needs to be done, but this looks quite promising! Thanks so much! Also, thanks for pointing out the file-system caveat. I'll have to test that in the near future. _______________________________________________ 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
