Documentation Source Text

Check-in [8a4435f7ae]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Add another example of using a stale file descriptor to the howtocorrupt page.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 8a4435f7aed6d100c82b9096e1b155d9ee3ce68abd6a3523d8fc4082db17a1ca
User & Date: drh 2019-07-11 13:28:27.061
Context
2019-07-11
14:15
Add the "quirks.html" document to the list of overview documents in the documentation summary. (check-in: 085c470f26 user: drh tags: trunk)
13:28
Add another example of using a stale file descriptor to the howtocorrupt page. (check-in: 8a4435f7ae user: drh tags: trunk)
2019-07-10
17:38
Version 3.29.0 (check-in: 059d7ea707 user: drh tags: trunk, release, version-3.29.0)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/howtocorrupt.in.
20
21
22
23
24
25
26

27
28
29
30
31
32
33
<h1> File overwrite by a rogue thread or process</h1>

<p>SQLite database files are ordinary disk files.
That means that any process can open the file and 
overwrite it with garbage.  There is nothing that the SQLite
library can do to defend against this.</p>


<h2> Continuing to use a file descriptor after it has been closed</h2>

<p>We have seen multiple cases where a file descriptor was open on a file,
then that file descriptor was closed and reopened on an SQLite database.
Later, some other thread continued to write into the
old file descriptor, not realizing that the original file had been closed
already.  But because the file descriptor had been reopened by SQLite,







>







20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<h1> File overwrite by a rogue thread or process</h1>

<p>SQLite database files are ordinary disk files.
That means that any process can open the file and 
overwrite it with garbage.  There is nothing that the SQLite
library can do to defend against this.</p>

<tcl>hd_fragment stalefd {stale file descriptor}</tcl>
<h2> Continuing to use a file descriptor after it has been closed</h2>

<p>We have seen multiple cases where a file descriptor was open on a file,
then that file descriptor was closed and reopened on an SQLite database.
Later, some other thread continued to write into the
old file descriptor, not realizing that the original file had been closed
already.  But because the file descriptor had been reopened by SQLite,
49
50
51
52
53
54
55








56
57
58
59
60
61
62
and later refuse to use low-numbered file descriptors
for database files. 
(See [SQLITE_MINIMUM_FILE_DESCRIPTOR] for additional information.)</p>

<p>Another example of corruption caused by using a closed file
descriptor was 
[https://code.facebook.com/posts/313033472212144/debugging-file-corruption-on-ios/|reported by facebook engineers] in a blog post on 2014-08-12.</p>









<h2> Backup or restore while a transaction is active</h2>

<p>Systems that run automatic backups in the background might try to
make a backup copy of an SQLite database file while it is in the middle
of a transaction.  The backup copy then might contain some old and some
new content, and thus be corrupt.</p>







>
>
>
>
>
>
>
>







50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
and later refuse to use low-numbered file descriptors
for database files. 
(See [SQLITE_MINIMUM_FILE_DESCRIPTOR] for additional information.)</p>

<p>Another example of corruption caused by using a closed file
descriptor was 
[https://code.facebook.com/posts/313033472212144/debugging-file-corruption-on-ios/|reported by facebook engineers] in a blog post on 2014-08-12.</p>

<p>Another example of this error was reported against
[https://fossil-scm.org/|Fossil] on 2019-07-11.  A file descriptor would
be opened for debugging output, but then closed and reopened by SQLite.
But the debugging logic continued to write into the original file
descriptor. See the
[https://fossil-scm.org/forum/forumpost/c51b9a1169|forum discussion]
for the bug report and a link to the fix.

<h2> Backup or restore while a transaction is active</h2>

<p>Systems that run automatic backups in the background might try to
make a backup copy of an SQLite database file while it is in the middle
of a transaction.  The backup copy then might contain some old and some
new content, and thus be corrupt.</p>