Core Data store corruption

Question

A handful of customers for my iPhone app are experiencing Core Data store corruption (I assume so, since the error is "Failed to save to data store: Operation could not be completed. (Cocoa error 259.)")

Has anyone else experienced this kind of store corruption? I am worried since I aim to soon push an update which performs a schema migration, and I am worried that this will expose even more problems.

I had assumed that the Core Data/SQLlite APIs use atomic operations and are immune to corruption except if the underlying filesystem experiences corruption.

Is there a way to reduce/prevent corruption, and a way to reproduce the corruption so I can test this (I have been unsuccessful thus far).

Edit:

Also getting this error: "The database at /var/mobile/Applications//Documents/foo.sqlite is corrupted. SQLite error code 11, database disk image is malformed."

Answer 1

The error you're getting is defined in Foundation.h

NSFileReadCorruptFileError = 259, // Read error (file corrupt, bad format, etc)

I've never encountered it with an actual store but I have hit something similar with bad permissions (on the Mac.) I haven't seen anyone mention a similar error online either. The error prevention systems in Core Data are fairly robust.

I would guess that the easiest way to create this would be send the persistent store to look at the wrong file such as accidentally targeting it at a text file. If it expects an SQL store but finds something else it will complain that the file is corrupt. That's just a shot in the dark.

Edit

This will be hard to track down because errors like this are so rare in Core Data that there aren't any tools to assist finding the problem.

I would recommend:

1. Checking upstream of where the error is coming from code. Perhaps something is throwing the store off or is causing it to look in another place.
2. Check anywhere you might do something non-standard. For example, if you generate your own entity map in code, its easy to throw it off if your not careful.

Answer 2

Also attempt to replicate the error by filling the drive on the Device -- you should receive a disk full error instead of the database corrupting, but it may be possible to get a corrupted database in this manner.

Answer 3

Are you ever interacting with the database using the sqlite API? Or have you used any non-Apple tools to create your seed database?

Answer 4

I recently ran across this problem. In my case I was performing a search and iterating over the objects to transform the data to XML and KML. I would then spawn the email handler and attach the files. Then I would update a field in the objects and finally save to the backing store (SQL Lite). The worked fine in 3.x. In 4.x it broke.

It was stupid on my part to do all the email handling before altering and saving the DB. Moving all non essential code to the point after the save cleared up this problem.

This problem would totally corrupt the SQL DB. In my case the error is:

 File at path does not appear to be a SQLite database