On Jan 22, 2019, at 9:02 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 22 Jan 2019, at 3:45pm, Maldonado-Salazar, Carlos > <carlos.maldonado-sala...@united.com> 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
