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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
