Re: UIDocument + NSFileWrapper crashes on opening
Re: UIDocument + NSFileWrapper crashes on opening
- Subject: Re: UIDocument + NSFileWrapper crashes on opening
- From: Quincey Morris <email@hidden>
- Date: Fri, 21 Jun 2013 10:06:27 -0700
On Jun 21, 2013, at 03:40 , Markus Spoettl <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden