In Sandvox we use Core Data with the binary store type as it's atomicity is more convenient for document management. Sadly it doesn't seem to receive anywhere near as much love as the SQLite store, no doubt due to lesser popularity.
The save process for atomic stores goes roughly:
- Validate changes
- Serialize all objects
- Write to disk
We found a crasher when saving the store in unusual circumstances. If the last step — writing to disk — fails, a mistake inside the binary store's implementation will deallocate the error rather and then pass a reference to it back up the stack. The caller will try to make use of the error and crash as it's now working with a zombie.
Apple were kind enough to supply us with a workaround: preflight the save to see if the store is likely writable:
Note that NSURLIsWritableKey is only available as of OS X 10.7 and iOS 5. If targeting older releases, you'll need to fall back to the older -[NSFileManager isWritableFileAtPath:].
I'm told the crasher is fixed as of OS X 10.8, but haven't verified that yet; it's certainly less likely to happen: On Mountain Lion, trying to open a store which Core Data can't write to earns you a console message that the store has been added as read-only and that "this will be a hard error in future". Suits me, so I detect having a read-only store and instead refuse to open the document. Thus the crasher should only be able to arise if the store becomes read-only while the document is already open.