On 13 Feb 2018, at 5:49pm, Chris Brody <chris.br...@gmail.com> wrote:

> I still have the following questions:


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 

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 

> 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


> - 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


> - 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


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.

sqlite-users mailing list

Reply via email to