On Jun 21, 2013, at 03:40 , Markus Spoettl <ms_li...@shiftoption.com> wrote:
> can it be that a wrapper which I hold on to from the time I first created it > switches it's backing from in-memory to memory mapped disk once it has been > saved? There are actually three possible states for a regular file wrapper: 1. 'regularFileContents' is a NSData instance whose data is in memory in the normal way 2. 'regularFileContents' is a NSData instance whose data is memory-mapped to a file 3. 'regularFileContents' is nil When you create a regular file wrapper with 'initRegularFileWithContents:', the initial state is #1. There is no documented API that will change this state to #2 or #3, other than releasing the file wrapper and creating a new one. When you create a file wrapper with 'initWithURL:options:error:', the initial state is #3, unless you use the 'NSFileWrapperReadingImmediate' option. This gets changed to #1 or #2 when you access the 'regularFileContents' property. When a save occurs, 'contentsForType:error:' returns a package wrapper that may be the one you were given originally, or may be one that you construct at save time. I believe, therefore, that the frameworks do nothing to sub-wrappers after you return the package wrapper for the save. For files that were edited, the sub-wrapper will be in state #1 (with the new data), and for files that weren't, the sub-wrapper will be in state #2 or #3 (depending on whether this particular instance was used to read the old data or not). The net effect is that only changed file data is hogging RAM, and the only way to "switch" the sub-wrappers back to state #3 is the recreate the package wrapper yourself. What's confusing about this is that it's hard to tell the difference between the ideal (state #3 except for sub-wrappers with freshly edited data) and the typical (state #2 for sub-wrappers whose data has been read). _______________________________________________ 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
