494 lines
28 KiB
HTML
494 lines
28 KiB
HTML
<!DOCTYPE html>
|
|
<html><head>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
|
<link href="../sqlite.css" rel="stylesheet">
|
|
<title>Standard File Control Opcodes</title>
|
|
<!-- path=../ -->
|
|
</head>
|
|
<body>
|
|
<div class=nosearch>
|
|
<a href="../index.html">
|
|
<img class="logo" src="../images/sqlite370_banner.gif" alt="SQLite" border="0">
|
|
</a>
|
|
<div><!-- IE hack to prevent disappearing logo --></div>
|
|
<div class="tagline desktoponly">
|
|
Small. Fast. Reliable.<br>Choose any three.
|
|
</div>
|
|
<div class="menu mainmenu">
|
|
<ul>
|
|
<li><a href="../index.html">Home</a>
|
|
<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
|
|
<li class='wideonly'><a href='../about.html'>About</a>
|
|
<li class='desktoponly'><a href="../docs.html">Documentation</a>
|
|
<li class='desktoponly'><a href="../download.html">Download</a>
|
|
<li class='wideonly'><a href='../copyright.html'>License</a>
|
|
<li class='desktoponly'><a href="../support.html">Support</a>
|
|
<li class='desktoponly'><a href="../prosupport.html">Purchase</a>
|
|
<li class='search' id='search_menubutton'>
|
|
<a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
|
|
</ul>
|
|
</div>
|
|
<div class="menu submenu" id="submenu">
|
|
<ul>
|
|
<li><a href='../about.html'>About</a>
|
|
<li><a href='../docs.html'>Documentation</a>
|
|
<li><a href='../download.html'>Download</a>
|
|
<li><a href='../support.html'>Support</a>
|
|
<li><a href='../prosupport.html'>Purchase</a>
|
|
</ul>
|
|
</div>
|
|
<div class="searchmenu" id="searchmenu">
|
|
<form method="GET" action="../search">
|
|
<select name="s" id="searchtype">
|
|
<option value="d">Search Documentation</option>
|
|
<option value="c">Search Changelog</option>
|
|
</select>
|
|
<input type="text" name="q" id="searchbox" value="">
|
|
<input type="submit" value="Go">
|
|
</form>
|
|
</div>
|
|
</div>
|
|
<script>
|
|
function toggle_div(nm) {
|
|
var w = document.getElementById(nm);
|
|
if( w.style.display=="block" ){
|
|
w.style.display = "none";
|
|
}else{
|
|
w.style.display = "block";
|
|
}
|
|
}
|
|
function toggle_search() {
|
|
var w = document.getElementById("searchmenu");
|
|
if( w.style.display=="block" ){
|
|
w.style.display = "none";
|
|
} else {
|
|
w.style.display = "block";
|
|
setTimeout(function(){
|
|
document.getElementById("searchbox").focus()
|
|
}, 30);
|
|
}
|
|
}
|
|
function div_off(nm){document.getElementById(nm).style.display="none";}
|
|
window.onbeforeunload = function(e){div_off("submenu");}
|
|
/* Disable the Search feature if we are not operating from CGI, since */
|
|
/* Search is accomplished using CGI and will not work without it. */
|
|
if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
|
|
document.getElementById("search_menubutton").style.display = "none";
|
|
}
|
|
/* Used by the Hide/Show button beside syntax diagrams, to toggle the */
|
|
function hideorshow(btn,obj){
|
|
var x = document.getElementById(obj);
|
|
var b = document.getElementById(btn);
|
|
if( x.style.display!='none' ){
|
|
x.style.display = 'none';
|
|
b.innerHTML='show';
|
|
}else{
|
|
x.style.display = '';
|
|
b.innerHTML='hide';
|
|
}
|
|
return false;
|
|
}
|
|
</script>
|
|
</div>
|
|
<!-- keywords: SQLITE_FCNTL_BEGIN_ATOMIC_WRITE SQLITE_FCNTL_BUSYHANDLER SQLITE_FCNTL_CHUNK_SIZE SQLITE_FCNTL_CKPT_DONE SQLITE_FCNTL_CKPT_START SQLITE_FCNTL_COMMIT_ATOMIC_WRITE SQLITE_FCNTL_COMMIT_PHASETWO SQLITE_FCNTL_DATA_VERSION SQLITE_FCNTL_FILE_POINTER SQLITE_FCNTL_GET_LOCKPROXYFILE SQLITE_FCNTL_HAS_MOVED SQLITE_FCNTL_JOURNAL_POINTER SQLITE_FCNTL_LAST_ERRNO SQLITE_FCNTL_LOCKSTATE SQLITE_FCNTL_LOCK_TIMEOUT SQLITE_FCNTL_MMAP_SIZE SQLITE_FCNTL_OVERWRITE SQLITE_FCNTL_PDB SQLITE_FCNTL_PERSIST_WAL SQLITE_FCNTL_POWERSAFE_OVERWRITE SQLITE_FCNTL_PRAGMA SQLITE_FCNTL_RBU SQLITE_FCNTL_RESERVE_BYTES SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE SQLITE_FCNTL_SET_LOCKPROXYFILE SQLITE_FCNTL_SIZE_HINT SQLITE_FCNTL_SIZE_LIMIT SQLITE_FCNTL_SYNC SQLITE_FCNTL_SYNC_OMITTED SQLITE_FCNTL_TEMPFILENAME SQLITE_FCNTL_TRACE SQLITE_FCNTL_VFSNAME SQLITE_FCNTL_VFS_POINTER SQLITE_FCNTL_WAL_BLOCK SQLITE_FCNTL_WIN32_AV_RETRY SQLITE_FCNTL_WIN32_GET_HANDLE SQLITE_FCNTL_WIN32_SET_HANDLE SQLITE_FCNTL_ZIPVFS {file control opcode} {file control opcodes} -->
|
|
<div class=nosearch>
|
|
<a href="intro.html"><h2>SQLite C Interface</h2></a>
|
|
<h2>Standard File Control Opcodes</h2>
|
|
</div>
|
|
<blockquote><pre>
|
|
#define SQLITE_FCNTL_LOCKSTATE 1
|
|
#define SQLITE_FCNTL_GET_LOCKPROXYFILE 2
|
|
#define SQLITE_FCNTL_SET_LOCKPROXYFILE 3
|
|
#define SQLITE_FCNTL_LAST_ERRNO 4
|
|
#define SQLITE_FCNTL_SIZE_HINT 5
|
|
#define SQLITE_FCNTL_CHUNK_SIZE 6
|
|
#define SQLITE_FCNTL_FILE_POINTER 7
|
|
#define SQLITE_FCNTL_SYNC_OMITTED 8
|
|
#define SQLITE_FCNTL_WIN32_AV_RETRY 9
|
|
#define SQLITE_FCNTL_PERSIST_WAL 10
|
|
#define SQLITE_FCNTL_OVERWRITE 11
|
|
#define SQLITE_FCNTL_VFSNAME 12
|
|
#define SQLITE_FCNTL_POWERSAFE_OVERWRITE 13
|
|
#define SQLITE_FCNTL_PRAGMA 14
|
|
#define SQLITE_FCNTL_BUSYHANDLER 15
|
|
#define SQLITE_FCNTL_TEMPFILENAME 16
|
|
#define SQLITE_FCNTL_MMAP_SIZE 18
|
|
#define SQLITE_FCNTL_TRACE 19
|
|
#define SQLITE_FCNTL_HAS_MOVED 20
|
|
#define SQLITE_FCNTL_SYNC 21
|
|
#define SQLITE_FCNTL_COMMIT_PHASETWO 22
|
|
#define SQLITE_FCNTL_WIN32_SET_HANDLE 23
|
|
#define SQLITE_FCNTL_WAL_BLOCK 24
|
|
#define SQLITE_FCNTL_ZIPVFS 25
|
|
#define SQLITE_FCNTL_RBU 26
|
|
#define SQLITE_FCNTL_VFS_POINTER 27
|
|
#define SQLITE_FCNTL_JOURNAL_POINTER 28
|
|
#define SQLITE_FCNTL_WIN32_GET_HANDLE 29
|
|
#define SQLITE_FCNTL_PDB 30
|
|
#define SQLITE_FCNTL_BEGIN_ATOMIC_WRITE 31
|
|
#define SQLITE_FCNTL_COMMIT_ATOMIC_WRITE 32
|
|
#define SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE 33
|
|
#define SQLITE_FCNTL_LOCK_TIMEOUT 34
|
|
#define SQLITE_FCNTL_DATA_VERSION 35
|
|
#define SQLITE_FCNTL_SIZE_LIMIT 36
|
|
#define SQLITE_FCNTL_CKPT_DONE 37
|
|
#define SQLITE_FCNTL_RESERVE_BYTES 38
|
|
#define SQLITE_FCNTL_CKPT_START 39
|
|
</pre></blockquote>
|
|
<p>
|
|
These integer constants are opcodes for the xFileControl method
|
|
of the <a href="../c3ref/io_methods.html">sqlite3_io_methods</a> object and for the <a href="../c3ref/file_control.html">sqlite3_file_control()</a>
|
|
interface.</p>
|
|
|
|
<p><ul>
|
|
<li><a name="sqlitefcntllockstate"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntllockstate">SQLITE_FCNTL_LOCKSTATE</a> opcode is used for debugging. This
|
|
opcode causes the xFileControl method to write the current state of
|
|
the lock (one of <a href="../c3ref/c_lock_exclusive.html">SQLITE_LOCK_NONE</a>, <a href="../c3ref/c_lock_exclusive.html">SQLITE_LOCK_SHARED</a>,
|
|
<a href="../c3ref/c_lock_exclusive.html">SQLITE_LOCK_RESERVED</a>, <a href="../c3ref/c_lock_exclusive.html">SQLITE_LOCK_PENDING</a>, or <a href="../c3ref/c_lock_exclusive.html">SQLITE_LOCK_EXCLUSIVE</a>)
|
|
into an integer that the pArg argument points to. This capability
|
|
is used during testing and is only available when the SQLITE_TEST
|
|
compile-time option is used.</p>
|
|
|
|
<p><li><a name="sqlitefcntlsizehint"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlsizehint">SQLITE_FCNTL_SIZE_HINT</a> opcode is used by SQLite to give the VFS
|
|
layer a hint of how large the database file will grow to be during the
|
|
current transaction. This hint is not guaranteed to be accurate but it
|
|
is often close. The underlying VFS might choose to preallocate database
|
|
file space based on this hint in order to help writes to the database
|
|
file run faster.</p>
|
|
|
|
<p><li><a name="sqlitefcntlsizelimit"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlsizelimit">SQLITE_FCNTL_SIZE_LIMIT</a> opcode is used by in-memory VFS that
|
|
implements <a href="../c3ref/deserialize.html">sqlite3_deserialize()</a> to set an upper bound on the size
|
|
of the in-memory database. The argument is a pointer to a <a href="../c3ref/int64.html">sqlite3_int64</a>.
|
|
If the integer pointed to is negative, then it is filled in with the
|
|
current limit. Otherwise the limit is set to the larger of the value
|
|
of the integer pointed to and the current database size. The integer
|
|
pointed to is set to the new limit.</p>
|
|
|
|
<p><li><a name="sqlitefcntlchunksize"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlchunksize">SQLITE_FCNTL_CHUNK_SIZE</a> opcode is used to request that the VFS
|
|
extends and truncates the database file in chunks of a size specified
|
|
by the user. The fourth argument to <a href="../c3ref/file_control.html">sqlite3_file_control()</a> should
|
|
point to an integer (type int) containing the new chunk-size to use
|
|
for the nominated database. Allocating database file space in large
|
|
chunks (say 1MB at a time), may reduce file-system fragmentation and
|
|
improve performance on some systems.</p>
|
|
|
|
<p><li><a name="sqlitefcntlfilepointer"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlfilepointer">SQLITE_FCNTL_FILE_POINTER</a> opcode is used to obtain a pointer
|
|
to the <a href="../c3ref/file.html">sqlite3_file</a> object associated with a particular database
|
|
connection. See also <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntljournalpointer">SQLITE_FCNTL_JOURNAL_POINTER</a>.</p>
|
|
|
|
<p><li><a name="sqlitefcntljournalpointer"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntljournalpointer">SQLITE_FCNTL_JOURNAL_POINTER</a> opcode is used to obtain a pointer
|
|
to the <a href="../c3ref/file.html">sqlite3_file</a> object associated with the journal file (either
|
|
the <a href="../lockingv3.html#rollback">rollback journal</a> or the <a href="../wal.html">write-ahead log</a>) for a particular database
|
|
connection. See also <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlfilepointer">SQLITE_FCNTL_FILE_POINTER</a>.</p>
|
|
|
|
<p><li><a name="sqlitefcntlsyncomitted"></a>
|
|
|
|
No longer in use.</p>
|
|
|
|
<p><li><a name="sqlitefcntlsync"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlsync">SQLITE_FCNTL_SYNC</a> opcode is generated internally by SQLite and
|
|
sent to the VFS immediately before the xSync method is invoked on a
|
|
database file descriptor. Or, if the xSync method is not invoked
|
|
because the user has configured SQLite with
|
|
<a href="../pragma.html#pragma_synchronous">PRAGMA synchronous=OFF</a> it is invoked in place
|
|
of the xSync method. In most cases, the pointer argument passed with
|
|
this file-control is NULL. However, if the database file is being synced
|
|
as part of a multi-database commit, the argument points to a nul-terminated
|
|
string containing the transactions super-journal file name. VFSes that
|
|
do not need this signal should silently ignore this opcode. Applications
|
|
should not call <a href="../c3ref/file_control.html">sqlite3_file_control()</a> with this opcode as doing so may
|
|
disrupt the operation of the specialized VFSes that do require it.</p>
|
|
|
|
<p><li><a name="sqlitefcntlcommitphasetwo"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlcommitphasetwo">SQLITE_FCNTL_COMMIT_PHASETWO</a> opcode is generated internally by SQLite
|
|
and sent to the VFS after a transaction has been committed immediately
|
|
but before the database is unlocked. VFSes that do not need this signal
|
|
should silently ignore this opcode. Applications should not call
|
|
<a href="../c3ref/file_control.html">sqlite3_file_control()</a> with this opcode as doing so may disrupt the
|
|
operation of the specialized VFSes that do require it.</p>
|
|
|
|
<p><li><a name="sqlitefcntlwin32avretry"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlwin32avretry">SQLITE_FCNTL_WIN32_AV_RETRY</a> opcode is used to configure automatic
|
|
retry counts and intervals for certain disk I/O operations for the
|
|
windows <a href="../vfs.html">VFS</a> in order to provide robustness in the presence of
|
|
anti-virus programs. By default, the windows VFS will retry file read,
|
|
file write, and file delete operations up to 10 times, with a delay
|
|
of 25 milliseconds before the first retry and with the delay increasing
|
|
by an additional 25 milliseconds with each subsequent retry. This
|
|
opcode allows these two values (10 retries and 25 milliseconds of delay)
|
|
to be adjusted. The values are changed for all database connections
|
|
within the same process. The argument is a pointer to an array of two
|
|
integers where the first integer is the new retry count and the second
|
|
integer is the delay. If either integer is negative, then the setting
|
|
is not changed but instead the prior value of that setting is written
|
|
into the array entry, allowing the current retry settings to be
|
|
interrogated. The zDbName parameter is ignored.</p>
|
|
|
|
<p><li><a name="sqlitefcntlpersistwal"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpersistwal">SQLITE_FCNTL_PERSIST_WAL</a> opcode is used to set or query the
|
|
persistent <a href="../wal.html">Write Ahead Log</a> setting. By default, the auxiliary
|
|
write ahead log (<a href="../wal.html#walfile">WAL file</a>) and shared memory
|
|
files used for transaction control
|
|
are automatically deleted when the latest connection to the database
|
|
closes. Setting persistent WAL mode causes those files to persist after
|
|
close. Persisting the files is useful when other processes that do not
|
|
have write permission on the directory containing the database file want
|
|
to read the database file, as the WAL and shared memory files must exist
|
|
in order for the database to be readable. The fourth parameter to
|
|
<a href="../c3ref/file_control.html">sqlite3_file_control()</a> for this opcode should be a pointer to an integer.
|
|
That integer is 0 to disable persistent WAL mode or 1 to enable persistent
|
|
WAL mode. If the integer is -1, then it is overwritten with the current
|
|
WAL persistence setting.</p>
|
|
|
|
<p><li><a name="sqlitefcntlpowersafeoverwrite"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpowersafeoverwrite">SQLITE_FCNTL_POWERSAFE_OVERWRITE</a> opcode is used to set or query the
|
|
persistent "powersafe-overwrite" or "PSOW" setting. The PSOW setting
|
|
determines the <a href="../c3ref/c_iocap_atomic.html">SQLITE_IOCAP_POWERSAFE_OVERWRITE</a> bit of the
|
|
xDeviceCharacteristics methods. The fourth parameter to
|
|
<a href="../c3ref/file_control.html">sqlite3_file_control()</a> for this opcode should be a pointer to an integer.
|
|
That integer is 0 to disable zero-damage mode or 1 to enable zero-damage
|
|
mode. If the integer is -1, then it is overwritten with the current
|
|
zero-damage mode setting.</p>
|
|
|
|
<p><li><a name="sqlitefcntloverwrite"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntloverwrite">SQLITE_FCNTL_OVERWRITE</a> opcode is invoked by SQLite after opening
|
|
a write transaction to indicate that, unless it is rolled back for some
|
|
reason, the entire database file will be overwritten by the current
|
|
transaction. This is used by VACUUM operations.</p>
|
|
|
|
<p><li><a name="sqlitefcntlvfsname"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlvfsname">SQLITE_FCNTL_VFSNAME</a> opcode can be used to obtain the names of
|
|
all <a href="../vfs.html">VFSes</a> in the VFS stack. The names are of all VFS shims and the
|
|
final bottom-level VFS are written into memory obtained from
|
|
<a href="../c3ref/free.html">sqlite3_malloc()</a> and the result is stored in the char* variable
|
|
that the fourth parameter of <a href="../c3ref/file_control.html">sqlite3_file_control()</a> points to.
|
|
The caller is responsible for freeing the memory when done. As with
|
|
all file-control actions, there is no guarantee that this will actually
|
|
do anything. Callers should initialize the char* variable to a NULL
|
|
pointer in case this file-control is not implemented. This file-control
|
|
is intended for diagnostic use only.</p>
|
|
|
|
<p><li><a name="sqlitefcntlvfspointer"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlvfspointer">SQLITE_FCNTL_VFS_POINTER</a> opcode finds a pointer to the top-level
|
|
<a href="../vfs.html">VFSes</a> currently in use. The argument X in
|
|
sqlite3_file_control(db,SQLITE_FCNTL_VFS_POINTER,X) must be
|
|
of type "<a href="../c3ref/vfs.html">sqlite3_vfs</a> **". This opcodes will set *X
|
|
to a pointer to the top-level VFS.
|
|
When there are multiple VFS shims in the stack, this opcode finds the
|
|
upper-most shim only.</p>
|
|
|
|
<p><li><a name="sqlitefcntlpragma"></a>
|
|
|
|
Whenever a <a href="../pragma.html#syntax">PRAGMA</a> statement is parsed, an <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a>
|
|
file control is sent to the open <a href="../c3ref/file.html">sqlite3_file</a> object corresponding
|
|
to the database file to which the pragma statement refers. The argument
|
|
to the <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a> file control is an array of
|
|
pointers to strings (char**) in which the second element of the array
|
|
is the name of the pragma and the third element is the argument to the
|
|
pragma or NULL if the pragma has no argument. The handler for an
|
|
<a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a> file control can optionally make the first element
|
|
of the char** argument point to a string obtained from <a href="../c3ref/mprintf.html">sqlite3_mprintf()</a>
|
|
or the equivalent and that string will become the result of the pragma or
|
|
the error message if the pragma fails. If the
|
|
<a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a> file control returns <a href="../rescode.html#notfound">SQLITE_NOTFOUND</a>, then normal
|
|
<a href="../pragma.html#syntax">PRAGMA</a> processing continues. If the <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a>
|
|
file control returns <a href="../rescode.html#ok">SQLITE_OK</a>, then the parser assumes that the
|
|
VFS has handled the PRAGMA itself and the parser generates a no-op
|
|
prepared statement if result string is NULL, or that returns a copy
|
|
of the result string if the string is non-NULL.
|
|
If the <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a> file control returns
|
|
any result code other than <a href="../rescode.html#ok">SQLITE_OK</a> or <a href="../rescode.html#notfound">SQLITE_NOTFOUND</a>, that means
|
|
that the VFS encountered an error while handling the <a href="../pragma.html#syntax">PRAGMA</a> and the
|
|
compilation of the PRAGMA fails with an error. The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a>
|
|
file control occurs at the beginning of pragma statement analysis and so
|
|
it is able to override built-in <a href="../pragma.html#syntax">PRAGMA</a> statements.</p>
|
|
|
|
<p><li><a name="sqlitefcntlbusyhandler"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlbusyhandler">SQLITE_FCNTL_BUSYHANDLER</a>
|
|
file-control may be invoked by SQLite on the database file handle
|
|
shortly after it is opened in order to provide a custom VFS with access
|
|
to the connection's busy-handler callback. The argument is of type (void**)
|
|
- an array of two (void *) values. The first (void *) actually points
|
|
to a function of type (int (*)(void *)). In order to invoke the connection's
|
|
busy-handler, this function should be invoked with the second (void *) in
|
|
the array as the only argument. If it returns non-zero, then the operation
|
|
should be retried. If it returns zero, the custom VFS should abandon the
|
|
current operation.</p>
|
|
|
|
<p><li><a name="sqlitefcntltempfilename"></a>
|
|
|
|
Applications can invoke the <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntltempfilename">SQLITE_FCNTL_TEMPFILENAME</a> file-control
|
|
to have SQLite generate a
|
|
temporary filename using the same algorithm that is followed to generate
|
|
temporary filenames for TEMP tables and other internal uses. The
|
|
argument should be a char** which will be filled with the filename
|
|
written into memory obtained from <a href="../c3ref/free.html">sqlite3_malloc()</a>. The caller should
|
|
invoke <a href="../c3ref/free.html">sqlite3_free()</a> on the result to avoid a memory leak.</p>
|
|
|
|
<p><li><a name="sqlitefcntlmmapsize"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlmmapsize">SQLITE_FCNTL_MMAP_SIZE</a> file control is used to query or set the
|
|
maximum number of bytes that will be used for memory-mapped I/O.
|
|
The argument is a pointer to a value of type sqlite3_int64 that
|
|
is an advisory maximum number of bytes in the file to memory map. The
|
|
pointer is overwritten with the old value. The limit is not changed if
|
|
the value originally pointed to is negative, and so the current limit
|
|
can be queried by passing in a pointer to a negative number. This
|
|
file-control is used internally to implement <a href="../pragma.html#pragma_mmap_size">PRAGMA mmap_size</a>.</p>
|
|
|
|
<p><li><a name="sqlitefcntltrace"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntltrace">SQLITE_FCNTL_TRACE</a> file control provides advisory information
|
|
to the VFS about what the higher layers of the SQLite stack are doing.
|
|
This file control is used by some VFS activity tracing <a href="../vfs.html#shim">shims</a>.
|
|
The argument is a zero-terminated string. Higher layers in the
|
|
SQLite stack may generate instances of this file control if
|
|
the <a href="../compile.html#use_fcntl_trace">SQLITE_USE_FCNTL_TRACE</a> compile-time option is enabled.</p>
|
|
|
|
<p><li><a name="sqlitefcntlhasmoved"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlhasmoved">SQLITE_FCNTL_HAS_MOVED</a> file control interprets its argument as a
|
|
pointer to an integer and it writes a boolean into that integer depending
|
|
on whether or not the file has been renamed, moved, or deleted since it
|
|
was first opened.</p>
|
|
|
|
<p><li><a name="sqlitefcntlwin32gethandle"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlwin32gethandle">SQLITE_FCNTL_WIN32_GET_HANDLE</a> opcode can be used to obtain the
|
|
underlying native file handle associated with a file handle. This file
|
|
control interprets its argument as a pointer to a native file handle and
|
|
writes the resulting value there.</p>
|
|
|
|
<p><li><a name="sqlitefcntlwin32sethandle"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlwin32sethandle">SQLITE_FCNTL_WIN32_SET_HANDLE</a> opcode is used for debugging. This
|
|
opcode causes the xFileControl method to swap the file handle with the one
|
|
pointed to by the pArg argument. This capability is used during testing
|
|
and only needs to be supported when SQLITE_TEST is defined.</p>
|
|
|
|
<p><li><a name="sqlitefcntlwalblock"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlwalblock">SQLITE_FCNTL_WAL_BLOCK</a> is a signal to the VFS layer that it might
|
|
be advantageous to block on the next WAL lock if the lock is not immediately
|
|
available. The WAL subsystem issues this signal during rare
|
|
circumstances in order to fix a problem with priority inversion.
|
|
Applications should <em>not</em> use this file-control.</p>
|
|
|
|
<p><li><a name="sqlitefcntlzipvfs"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlzipvfs">SQLITE_FCNTL_ZIPVFS</a> opcode is implemented by zipvfs only. All other
|
|
VFS should return SQLITE_NOTFOUND for this opcode.</p>
|
|
|
|
<p><li><a name="sqlitefcntlrbu"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlrbu">SQLITE_FCNTL_RBU</a> opcode is implemented by the special VFS used by
|
|
the RBU extension only. All other VFS should return SQLITE_NOTFOUND for
|
|
this opcode.</p>
|
|
|
|
<p><li><a name="sqlitefcntlbeginatomicwrite"></a>
|
|
|
|
If the <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlbeginatomicwrite">SQLITE_FCNTL_BEGIN_ATOMIC_WRITE</a> opcode returns SQLITE_OK, then
|
|
the file descriptor is placed in "batch write mode", which
|
|
means all subsequent write operations will be deferred and done
|
|
atomically at the next <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlcommitatomicwrite">SQLITE_FCNTL_COMMIT_ATOMIC_WRITE</a>. Systems
|
|
that do not support batch atomic writes will return SQLITE_NOTFOUND.
|
|
Following a successful SQLITE_FCNTL_BEGIN_ATOMIC_WRITE and prior to
|
|
the closing <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlcommitatomicwrite">SQLITE_FCNTL_COMMIT_ATOMIC_WRITE</a> or
|
|
<a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlrollbackatomicwrite">SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE</a>, SQLite will make
|
|
no VFS interface calls on the same <a href="../c3ref/file.html">sqlite3_file</a> file descriptor
|
|
except for calls to the xWrite method and the xFileControl method
|
|
with <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlsizehint">SQLITE_FCNTL_SIZE_HINT</a>.</p>
|
|
|
|
<p><li><a name="sqlitefcntlcommitatomicwrite"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlcommitatomicwrite">SQLITE_FCNTL_COMMIT_ATOMIC_WRITE</a> opcode causes all write
|
|
operations since the previous successful call to
|
|
<a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlbeginatomicwrite">SQLITE_FCNTL_BEGIN_ATOMIC_WRITE</a> to be performed atomically.
|
|
This file control returns <a href="../rescode.html#ok">SQLITE_OK</a> if and only if the writes were
|
|
all performed successfully and have been committed to persistent storage.
|
|
Regardless of whether or not it is successful, this file control takes
|
|
the file descriptor out of batch write mode so that all subsequent
|
|
write operations are independent.
|
|
SQLite will never invoke SQLITE_FCNTL_COMMIT_ATOMIC_WRITE without
|
|
a prior successful call to <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlbeginatomicwrite">SQLITE_FCNTL_BEGIN_ATOMIC_WRITE</a>.</p>
|
|
|
|
<p><li><a name="sqlitefcntlrollbackatomicwrite"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlrollbackatomicwrite">SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE</a> opcode causes all write
|
|
operations since the previous successful call to
|
|
<a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlbeginatomicwrite">SQLITE_FCNTL_BEGIN_ATOMIC_WRITE</a> to be rolled back.
|
|
This file control takes the file descriptor out of batch write mode
|
|
so that all subsequent write operations are independent.
|
|
SQLite will never invoke SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE without
|
|
a prior successful call to <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlbeginatomicwrite">SQLITE_FCNTL_BEGIN_ATOMIC_WRITE</a>.</p>
|
|
|
|
<p><li><a name="sqlitefcntllocktimeout"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntllocktimeout">SQLITE_FCNTL_LOCK_TIMEOUT</a> opcode is used to configure a VFS
|
|
to block for up to M milliseconds before failing when attempting to
|
|
obtain a file lock using the xLock or xShmLock methods of the VFS.
|
|
The parameter is a pointer to a 32-bit signed integer that contains
|
|
the value that M is to be set to. Before returning, the 32-bit signed
|
|
integer is overwritten with the previous value of M.</p>
|
|
|
|
<p><li><a name="sqlitefcntldataversion"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntldataversion">SQLITE_FCNTL_DATA_VERSION</a> opcode is used to detect changes to
|
|
a database file. The argument is a pointer to a 32-bit unsigned integer.
|
|
The "data version" for the pager is written into the pointer. The
|
|
"data version" changes whenever any change occurs to the corresponding
|
|
database file, either through SQL statements on the same database
|
|
connection or through transactions committed by separate database
|
|
connections possibly in other processes. The <a href="../c3ref/total_changes.html">sqlite3_total_changes()</a>
|
|
interface can be used to find if any database on the connection has changed,
|
|
but that interface responds to changes on TEMP as well as MAIN and does
|
|
not provide a mechanism to detect changes to MAIN only. Also, the
|
|
<a href="../c3ref/total_changes.html">sqlite3_total_changes()</a> interface responds to internal changes only and
|
|
omits changes made by other database connections. The
|
|
<a href="../pragma.html#pragma_data_version">PRAGMA data_version</a> command provides a mechanism to detect changes to
|
|
a single attached database that occur due to other database connections,
|
|
but omits changes implemented by the database connection on which it is
|
|
called. This file control is the only mechanism to detect changes that
|
|
happen either internally or externally and that are associated with
|
|
a particular attached database.</p>
|
|
|
|
<p><li><a name="sqlitefcntlckptstart"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlckptstart">SQLITE_FCNTL_CKPT_START</a> opcode is invoked from within a checkpoint
|
|
in wal mode before the client starts to copy pages from the wal
|
|
file to the database file.</p>
|
|
|
|
<p><li><a name="sqlitefcntlckptdone"></a>
|
|
|
|
The <a href="../c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlckptdone">SQLITE_FCNTL_CKPT_DONE</a> opcode is invoked from within a checkpoint
|
|
in wal mode after the client has finished copying pages from the wal
|
|
file to the database file, but before the *-shm file is updated to
|
|
record the fact that the pages have been checkpointed.
|
|
</ul>
|
|
</p><p>See also lists of
|
|
<a href="objlist.html">Objects</a>,
|
|
<a href="constlist.html">Constants</a>, and
|
|
<a href="funclist.html">Functions</a>.</p>
|