On 13 Feb 2018, at 5:49pm, Chris Brody <chris.br...@gmail.com> wrote:
> I still have the following questions: Chris, There are two possibilities: A) The SQLite API was used correctly, including being allowed to close all files it opened. B) Any other situation. If (A) happened, you can predict things about the database header and you can rely on SQLite documentation about the format of files it uses. Otherwise you can't. However, the SQLite library goes through heroic measures, every time it opens a database, to detect whether the database was closed correctly and, if it sees any problem, to rescue an uncorrupt version of the database. All you need to do is open the SQLite database using the SQLite API, and SQLite will take any measures necessary to remedy the results of any power-loss or crash, including returning an error message if it can't arrive at an uncorrupt version of the database. > 3. rogue code writes data to the file descriptor in use by sqlite As is true for any library which handles files, nothing can be done about something external overwriting the file. However, there is no way within the SQLite API to list the a file handles that a SQLite connection is using. Anything trying to mess with SQLite's file handles would have to arrive at the handle using random numbers, or at the operating system level. > My understanding is that iOS applications with shared databases can be > especially sensitive to sqlite headers This is not true as long as the iOS applications are using the standard SQLite API to access its databases. There is nothing strange about iOS in this regard, it's just another version of Unix and works the same as other versions of Unix / Linux. The Apple reference you provided refer to obsolete versions of iOS. The current version of iOS is version 10, which no longer makes assumptions about SQLite database. From the Apple page you referred to: "This has since been resolved in iOS 8.2." The SQLCipher page seems to indicate that SQLCipher is not compatible with a particular, rarely-used, feature of iOS 8. The text in the page you supply states clearly that the use SQLCipher makes of this Apple feature is not properly supported. This has nothing to do with SQLite. A comment near the foot of the page you referred to says "We consider this issue resolved. Thanks @sjlombardo and team!" > - Any recommended explanations or resources that explain how iOS > handles shared sqlite databases (in more detail, with simpler terms)? iOS does not handle shared SQLite databases itself. The 'sharing' is done by the same SQLite API used on other platforms. iOS would not even know that a database is being shared. Details on how SQLite handles shared databases can be found at <https://sqlite.org/lockingv3.html> > - Any recommended explanations or resources to understand how and when > sqlite header may be in inconsistent or otherwise incorrect state? The SQLite header is less than 100 bytes long. It all fits within one sector / page of a storage device i.e. the entire header is written in one operation. If you ever discover an inconsistent header there's a bug in SQLite. The contents of the header are listed in <https://sqlite.org/fileformat.html#the_database_header> > - Any recommended explanations or resources to understand how it may > be possible to obtain the correct sqlite database information (such as > WAL or other journal mode, actual database size, number of pages, > page/cache size, etc.)? PRAGMAs are available for retrieving all this information. See <https://sqlite.org/pragma.html#pragma_journal_mode> <https://sqlite.org/pragma.html#pragma_page_count> <https://sqlite.org/pragma.html#pragma_page_size> The size of the database is page_count * page_size. Other PRAGMAs on the same page provide other information which might be covered in your "etc.". If you have any other questions, please do not hesitate to ask them here. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
