Documentation Source Text

<p>Beginning with SQLite [version 3.10.0] ([dateof:3.10.0]), 
the unix OS interface will
attempt to resolve symbolic links and open the database file by its
canonical name.  Prior to version 3.10.0, opening a database file 
through a symbolic link was similar to opening a database file
that had multiple hard links and resulted in undefined behavior.</p>

<tcl>hd_fragment fork</tcl>
<h2> Carrying an open database connection across a fork() </h2>

<p> Do not open an SQLite database connection, then fork(), then try
to use that database connection in the child process.  All kinds of
locking problems will result and you can easily end up with a corrupt
database.  SQLite is not designed to support that kind of behavior.
Any database connection that is used in a child process must be opened
in the child process, not inherited from the parent.

<p> Do not even call [sqlite3_close()] on a database connection from a
child process if the connection was opened in the parent.  It is safe
to close the underlying file descriptor, but the [sqlite3_close()]
interface might invoke cleanup activities that will delete content out
from under the parent, leading to errors and perhaps even database
corruption.

<h1> Failure to sync</h1>

<p>In order to guarantee that database files are always consistent, SQLite
will occasionally ask the operating system to flush all pending writes to
persistent storage then wait for that flush to complete.  This is 
accomplished using the <tt>fsync()</tt> system call under unix and