** SQLite uses one of these integer values as the second** argument to calls it makes to the xLock() and xUnlock() methods** of an [sqlite3_io_methods] object.*/#define SQLITE_LOCK_NONE          0#define SQLITE_LOCK_SHARED        1#define SQLITE_LOCK_RESERVED      2#define SQLITE_LOCK_PENDING       3#define SQLITE_LOCK_EXCLUSIVE     4/*** CAPI3REF: Synchronization Type Flags {H10260} <H11120>**** When SQLite invokes the xSync() method of an** [sqlite3_io_methods] object it uses a combination of** these integer values as the second argument.**** When the SQLITE_SYNC_DATAONLY flag is used, it means that the** sync operation only needs to flush data to mass storage.  Inode** information need not be flushed. The SQLITE_SYNC_NORMAL flag means** to use normal fsync() semantics. The SQLITE_SYNC_FULL flag means** to use Mac OS X style fullsync instead of fsync().*/#define SQLITE_SYNC_NORMAL        0x00002#define SQLITE_SYNC_FULL          0x00003#define SQLITE_SYNC_DATAONLY      0x00010/*** CAPI3REF: OS Interface Open File Handle {H11110} <S20110>**** An [sqlite3_file] object represents an open file in the OS** interface layer.  Individual OS interface implementations will** want to subclass this object by appending additional fields** for their own use.  The pMethods entry is a pointer to an** [sqlite3_io_methods] object that defines methods for performing** I/O operations on the open file.*/typedef struct sqlite3_file sqlite3_file;struct sqlite3_file {  const struct sqlite3_io_methods *pMethods;  /* Methods for an open file */};/*** CAPI3REF: OS Interface File Virtual Methods Object {H11120} <S20110>**** Every file opened by the [sqlite3_vfs] xOpen method populates an** [sqlite3_file] object (or, more commonly, a subclass of the** [sqlite3_file] object) with a pointer to an instance of this object.** This object defines the methods used to perform various operations** against the open file represented by the [sqlite3_file] object.**** The flags argument to xSync may be one of [SQLITE_SYNC_NORMAL] or** [SQLITE_SYNC_FULL].  The first choice is the normal fsync().** The second choice is a Mac OS X style fullsync.  The [SQLITE_SYNC_DATAONLY]** flag may be ORed in to indicate that only the data of the file** and not its inode needs to be synced.**** The integer values to xLock() and xUnlock() are one of** <ul>** <li> [SQLITE_LOCK_NONE],** <li> [SQLITE_LOCK_SHARED],** <li> [SQLITE_LOCK_RESERVED],** <li> [SQLITE_LOCK_PENDING], or** <li> [SQLITE_LOCK_EXCLUSIVE].** </ul>** xLock() increases the lock. xUnlock() decreases the lock.** The xCheckReservedLock() method checks whether any database connection,** either in this process or in some other process, is holding a RESERVED,** PENDING, or EXCLUSIVE lock on the file.  It returns true** if such a lock exists and false otherwise.**** The xFileControl() method is a generic interface that allows custom** VFS implementations to directly control an open file using the** [sqlite3_file_control()] interface.  The second "op" argument is an** integer opcode.  The third argument is a generic pointer intended to** point to a structure that may contain arguments or space in which to** write return values.  Potential uses for xFileControl() might be** functions to enable blocking locks with timeouts, to change the** locking strategy (for example to use dot-file locks), to inquire** about the status of a lock, or to break stale locks.  The SQLite** core reserves all opcodes less than 100 for its own use.** A [SQLITE_FCNTL_LOCKSTATE | list of opcodes] less than 100 is available.** Applications that define a custom xFileControl method should use opcodes** greater than 100 to avoid conflicts.**** The xSectorSize() method returns the sector size of the** device that underlies the file.  The sector size is the** minimum write that can be performed without disturbing** other bytes in the file.  The xDeviceCharacteristics()** method returns a bit vector describing behaviors of the** underlying device:**** <ul>** <li> [SQLITE_IOCAP_ATOMIC]** <li> [SQLITE_IOCAP_ATOMIC512]** <li> [SQLITE_IOCAP_ATOMIC1K]** <li> [SQLITE_IOCAP_ATOMIC2K]** <li> [SQLITE_IOCAP_ATOMIC4K]** <li> [SQLITE_IOCAP_ATOMIC8K]** <li> [SQLITE_IOCAP_ATOMIC16K]** <li> [SQLITE_IOCAP_ATOMIC32K]** <li> [SQLITE_IOCAP_ATOMIC64K]** <li> [SQLITE_IOCAP_SAFE_APPEND]** <li> [SQLITE_IOCAP_SEQUENTIAL]** </ul>**** The SQLITE_IOCAP_ATOMIC property means that all writes of** any size are atomic.  The SQLITE_IOCAP_ATOMICnnn values** mean that writes of blocks that are nnn bytes in size and** are aligned to an address which is an integer multiple of** nnn are atomic.  The SQLITE_IOCAP_SAFE_APPEND value means** that when data is appended to a file, the data is appended** first then the size of the file is extended, never the other** way around.  The SQLITE_IOCAP_SEQUENTIAL property means that** information is written to disk in the same order as calls** to xWrite().**** If xRead() returns SQLITE_IOERR_SHORT_READ it must also fill** in the unread portions of the buffer with zeros.  A VFS that** fails to zero-fill short reads might seem to work.  However,** failure to zero-fill short reads will eventually lead to** database corruption.*/typedef struct sqlite3_io_methods sqlite3_io_methods;struct sqlite3_io_methods {  int iVersion;  int (*xClose)(sqlite3_file*);  int (*xRead)(sqlite3_file*, void*, int iAmt, sqlite3_int64 iOfst);  int (*xWrite)(sqlite3_file*, const void*, int iAmt, sqlite3_int64 iOfst);  int (*xTruncate)(sqlite3_file*, sqlite3_int64 size);  int (*xSync)(sqlite3_file*, int flags);  int (*xFileSize)(sqlite3_file*, sqlite3_int64 *pSize);  int (*xLock)(sqlite3_file*, int);  int (*xUnlock)(sqlite3_file*, int);  int (*xCheckReservedLock)(sqlite3_file*, int *pResOut);  int (*xFileControl)(sqlite3_file*, int op, void *pArg);  int (*xSectorSize)(sqlite3_file*);  int (*xDeviceCharacteristics)(sqlite3_file*);  /* Additional methods may be added in future releases */};/*** CAPI3REF: Standard File Control Opcodes {H11310} <S30800>**** These integer constants are opcodes for the xFileControl method** of the [sqlite3_io_methods] object and for the [sqlite3_file_control()]** interface.**** The [SQLITE_FCNTL_LOCKSTATE] opcode is used for debugging.  This** opcode causes the xFileControl method to write the current state of** the lock (one of [SQLITE_LOCK_NONE], [SQLITE_LOCK_SHARED],** [SQLITE_LOCK_RESERVED], [SQLITE_LOCK_PENDING], or [SQLITE_LOCK_EXCLUSIVE])** into an integer that the pArg argument points to. This capability** is used during testing and only needs to be supported when SQLITE_TEST** is defined.*/#define SQLITE_FCNTL_LOCKSTATE        1#define SQLITE_GET_LOCKPROXYFILE      2#define SQLITE_SET_LOCKPROXYFILE      3#define SQLITE_LAST_ERRNO             4/*** CAPI3REF: Mutex Handle {H17110} <S20130>**** The mutex module within SQLite defines [sqlite3_mutex] to be an** abstract type for a mutex object.  The SQLite core never looks** at the internal representation of an [sqlite3_mutex].  It only** deals with pointers to the [sqlite3_mutex] object.**** Mutexes are created using [sqlite3_mutex_alloc()].*/typedef struct sqlite3_mutex sqlite3_mutex;/*** CAPI3REF: OS Interface Object {H11140} <S20100>**** An instance of the sqlite3_vfs object defines the interface between** the SQLite core and the underlying operating system.  The "vfs"** in the name of the object stands for "virtual file system".**** The value of the iVersion field is initially 1 but may be larger in** future versions of SQLite.  Additional fields may be appended to this** object when the iVersion value is increased.  Note that the structure** of the sqlite3_vfs object changes in the transaction between** SQLite version 3.5.9 and 3.6.0 and yet the iVersion field was not** modified.**** The szOsFile field is the size of the subclassed [sqlite3_file]** structure used by this VFS.  mxPathname is the maximum length of** a pathname in this VFS.**** Registered sqlite3_vfs objects are kept on a linked list formed by** the pNext pointer.  The [sqlite3_vfs_register()]** and [sqlite3_vfs_unregister()] interfaces manage this list** in a thread-safe way.  The [sqlite3_vfs_find()] interface** searches the list.  Neither the application code nor the VFS** implementation should use the pNext pointer.**** The pNext field is the only field in the sqlite3_vfs** structure that SQLite will ever modify.  SQLite will only access** or modify this field while holding a particular static mutex.** The application should never modify anything within the sqlite3_vfs** object once the object has been registered.**** The zName field holds the name of the VFS module.  The name must** be unique across all VFS modules.**** SQLite will guarantee that the zFilename parameter to xOpen** is either a NULL pointer or string obtained** from xFullPathname().  SQLite further guarantees that** the string will be valid and unchanged until xClose() is** called. Because of the previous sentense,** the [sqlite3_file] can safely store a pointer to the** filename if it needs to remember the filename for some reason.** If the zFilename parameter is xOpen is a NULL pointer then xOpen** must invite its own temporary name for the file.  Whenever the ** xFilename parameter is NULL it will also be the case that the** flags parameter will include [SQLITE_OPEN_DELETEONCLOSE].**** The flags argument to xOpen() includes all bits set in** the flags argument to [sqlite3_open_v2()].  Or if [sqlite3_open()]** or [sqlite3_open16()] is used, then flags includes at least** [SQLITE_OPEN_READWRITE] | [SQLITE_OPEN_CREATE]. ** If xOpen() opens a file read-only then it sets *pOutFlags to** include [SQLITE_OPEN_READONLY].  Other bits in *pOutFlags may be set.**** SQLite will also add one of the following flags to the xOpen()** call, depending on the object being opened:**** <ul>** <li>  [SQLITE_OPEN_MAIN_DB]** <li>  [SQLITE_OPEN_MAIN_JOURNAL]** <li>  [SQLITE_OPEN_TEMP_DB]** <li>  [SQLITE_OPEN_TEMP_JOURNAL]** <li>  [SQLITE_OPEN_TRANSIENT_DB]** <li>  [SQLITE_OPEN_SUBJOURNAL]** <li>  [SQLITE_OPEN_MASTER_JOURNAL]** </ul>**** The file I/O implementation can use the object type flags to** change the way it deals with files.  For example, an application** that does not care about crash recovery or rollback might make** the open of a journal file a no-op.  Writes to this journal would** also be no-ops, and any attempt to read the journal would return** SQLITE_IOERR.  Or the implementation might recognize that a database** file will be doing page-aligned sector reads and writes in a random** order and set up its I/O subsystem accordingly.**** SQLite might also add one of the following flags to the xOpen method:**** <ul>** <li> [SQLITE_OPEN_DELETEONCLOSE]** <li> [SQLITE_OPEN_EXCLUSIVE]** </ul>**** The [SQLITE_OPEN_DELETEONCLOSE] flag means the file should be** deleted when it is closed.  The [SQLITE_OPEN_DELETEONCLOSE]** will be set for TEMP  databases, journals and for subjournals.**** The [SQLITE_OPEN_EXCLUSIVE] flag means the file should be opened** for exclusive access.  This flag is set for all files except** for the main database file.**** At least szOsFile bytes of memory are allocated by SQLite** to hold the  [sqlite3_file] structure passed as the third** argument to xOpen.  The xOpen method does not have to** allocate the structure; it should just fill it in.**** The flags argument to xAccess() may be [SQLITE_ACCESS_EXISTS]** to test for the existence of a file, or [SQLITE_ACCESS_READWRITE] to** test whether a file is readable and writable, or [SQLITE_ACCESS_READ]** to test whether a file is at least readable.   The file can be a** directory.**** SQLite will always allocate at least mxPathname+1 bytes for the** output buffer xFullPathname.  The exact size of the output buffer** is also passed as a parameter to both  methods. If the output buffer** is not large enough, [SQLITE_CANTOPEN] should be returned. Since this is** handled as a fatal error by SQLite, vfs implementations should endeavor** to prevent this by setting mxPathname to a sufficiently large value.**** The xRandomness(), xSleep(), and xCurrentTime() interfaces** are not strictly a part of the filesystem, but they are** included in the VFS structure for completeness.** The xRandomness() function attempts to return nBytes bytes