Duplicated Non-WAL NSPersistentDocument Has WAL

Number:rdar://15873041 Date Originated:2014 Jan 21
Status:Open Resolved:
Product:OS X SDK Product Version:10.9.1
Classification:Pretty serious Reproducible:Always
Jerome Krinock   21-Jan-2014 04:04 PM

Trouble occurs if a developer updates an older SQLite document-based Core Data app, and in so doing links against the 10.9 SDK, but does not update the app’s document to use the new package-based "file wrapper".  By default, the new build will adopt the new default journal mode = write-ahead logging (WAL).

Mac users associate documents with files.  As far as the app user is concerned, the document file is still the sqlite database file.  However, the updated app will produce -shm and -wal files, along side the document file, are junk.  The user will likely think that these files are temporary junk, and may move the document file without moving the -shm or -wal file, or else trash the -shm or -wal file.  In either case, document data will be corrupted.

So there are two ways for the developer to solve this problem, either (1) update app to file wrappers or (2) opt out of WAL journal mode.

(1) Updating to file wrappers is not easy because, according to NSPersistentDocument Class Documentation, "NSPersistentDocument does not support … File wrappers … See 'File Wrappers with Core Data Documents' for an example of how you can add support for file wrappers."  There is no hyperlink and I cannot find such a document, although Sean McBride says he did find it, and it was labelled ""Retired Document.  This sample code may not represent best practices for current development".  An alternative may be to use Mike Abdullah's BSManagedDocument from github.com.  However I presume that, however this is done, it will  break compatibility with old documents, requiring a migration process of some kind.  So developers may choose the next method instead.

(2) The Core Data Release Notes for 10.9 explain how to opt out of WAL by passing a pragma to SQLite.  This appears to work at first.  However, if Lion Autosave (+autosavesInPlace) is opted in to, when the user duplicates the document, unexpectedly, the duplicated document apparently defaults back to WAL journal mode.  The duplicated document is therefore subject to corruption and data loss, as explained above.

Steps to Reproduce:

Download the Apple Sample Project named "Reviews".  In the Info.plist, delete the "Binary" and "XML" document types, so that "SQLite" is used.  Also add two implementations in Reviews.m, to activate Lion Autosaving and to opt the SQLite journal mode back to the old "DELETE" mode.

This work has already been done for you in the attached sample project.  So, here's where you start…

1.  Build and Run the product.
2.  Click in the menu: File > New.  A document will open.
3.  Click in the menu: File > Duplicate.  A new document will very cutely pop out of the first document.
4.  Click in the menu: File > Close.  A "Do you want to keep this…" sheet appears.
5.  Note where the document is going to be located.
6.  Name the document: "Test.review"
7.  Click the "Save" button.
8.  Open a Finder window to the folder where the document is located.

Expected Results:
You should see one document file named "Test.review".

Actual Results:
You see three document files: "Test.review", "Test.review-shm",  and "Test.review-wal".

OS X 10.9.1

This may be a duplicate of Bug 15854533 filed by Romain Piveteau.  But in case he didn't include a sample project, I have.


'CoreDataNoWAL.zip' was successfully uploaded.


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!