Re: Checking integrity of a Core Data document with SQLite store
Re: Checking integrity of a Core Data document with SQLite store
- Subject: Re: Checking integrity of a Core Data document with SQLite store
- From: Ben Trumbull <email@hidden>
- Date: Wed, 17 Mar 2010 23:35:01 -0700
The integrity check will do that, but there's no way to mitigate the I/O costs. Conceptually, if you added a simple checksum, you'd still have to read the entire file to verify it matched the checksum.
This file corruption should be extremely rare, and should only occur after power loss or kernel panic or a user hitting the power button for an unclean reboot. If not, please file a bug. If so, but you have data you are willing to share with us, also please file a bug.
- Ben
On Mar 17, 2010, at 10:04 PM, Dave Fernandes wrote:
> Thanks, Ben and mmalc for the responses.
>
> I found that prefetching the commonly accessed objects in my document's initWithContentsOfURL:ofType:error method finds the corruption pretty reliably. Hopefully, this is a reasonably robust check without being as i/o intensive as an integrity check.
>
> It would be nice, though, to have a method that I was sure provided good coverage of the physical file.
>
> Dave
>
> On 2010-03-15, at 11:03 PM, Ben Trumbull wrote:
>
>>
>> On Mar 15, 2010, at 7:49 PM, Dave Fernandes wrote:
>>
>>>
>>> On 2010-03-15, at 3:30 PM, Ben Trumbull wrote:
>>>
>>>> Running an integrity check can be useful if you have previously gotten a corrupt db error back from fetching or saving, or your app previously crashed, or you have some other active indicator it might be worthwhile. However, it's quiet expensive in I/O and you should not do it on every app launch / document open. Customers with account home directories on AFP, NFS or SMB servers will be very unhappy, and if your files become large enough so will people using local drives.
>>>
>>> That's a shame. It would certainly be easier to check when opening the file than to scatter code all over the app to diagnose the problem. Is there a standard exception I can expect to get when fetching or saving? NSInternalInconsistencyException is the one I currently get.
>>
>> You should generally get an NSError with the code that is NSFileReadCorruptFileError. In gdb, what does:
>>
>>> future-break objc_exception_throw
>>> future-break +[NSError errorWithDomain:code:userInfo:]
>>
>> ...
>>
>>> info threads
>>> thread apply all bt
>>
>> say ?
>>
>> The only place you should get an exception is if you try to fault in an object that is unreachable. Either because the database was deleted or corrupted, or because another thread / context deleted that object you wanted before you and you only held the reference instead of getting all the data at once (e.g. race on delete)
>>
>> - Ben
>>
>
_______________________________________________
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