On Jan 22, 2019, at 9:02 AM, Simon Slavin wrote:
>
> On 22 Jan 2019, at 3:45pm, Maldonado-Salazar, Carlos
> wrote:
>
>> Is there a way to know when CoreData closes sqlite files?. I’m using
>> CoreData in an iOS app and I set file attributes for sqlite file to be
>> NSFileProtectionCompleteUnlessOpen which throws away the key to encrypt the
>> file when it’s closed, denying access to it.
>
> I don't think I've seen one. Technically, CoreData might hold its file open
> after your application has quit, for example if it's doing lazy writing. So
> there'd be nothing to notify
A persistent store coordinator will close its handle when the store is removed.
This happens naturally when the coordinator is deallocated, or you can do it
manually using -[NSPersistentStoreCoordinator removePersistentStore:error:].
One common problem people run into is unexpected object lifetime extension when
the coordinator gets added to a autorelease pool higher up in the call stack.
In those conditions you can make the lifetime semantics of the coordinator more
precise through explicit use of @autoreleasepool blocks.
> Using NSFileProtectionCompleteUnlessOpen or NSFileProtectionComplete should
> do a good job of keeping your data secure.
I'd recommend using NSFileProtectionComplete over
NSFileProtectionCompleteUnlessOpen. The former is simpler and self-securing
(the filesystem will return an error if Core Data attempts to read or write
data when the device is locked).
Scott
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
