Glossary
SQLite freelist
The list of whole database pages that SQLite no longer uses and keeps for reuse, often with their old content still in place.
The freelist is SQLite's list of whole pages that belong to the database file but no longer hold any live data. When deletions empty a page, SQLite does not shrink the file (unless auto-vacuum is enabled); it records the page on the freelist and reuses it the next time it needs a page (file format).
The list is reachable from the 100-byte database header: the 4-byte big-endian integer at offset 32 is the page number of the first freelist trunk page, and the one at offset 36 is the total number of freelist pages. Each trunk page starts with the number of the next trunk page and a count, followed by an array of leaf page numbers. Leaf pages carry no freelist structure of their own, so their previous content is typically left in place.
Why it matters in investigations
A notification database churns constantly: toasts arrive, expire and are dismissed. When a whole page of Notification rows is emptied, that page moves to the freelist with its old records still readable, unless secure_delete is on. A single freelist page can therefore hold several deleted notifications at once. It is overwritten only when SQLite reuses the page, or wiped when the database is vacuumed, so recovery works best on recently collected files. As with any carved data, a recovered row is best-effort evidence.
Example
Database header, offset 32: 00 00 00 0C first trunk page = 12
offset 36: 00 00 00 03 3 freelist pages in total
Page 12 (trunk): 00 00 00 00 no further trunk page
00 00 00 02 2 leaf pages follow
00 00 00 07 00 00 00 0F leaves: 7, 15
A notification carved from page 15 appears in the parser with the source freelist page 15.
Related terms
The Windows Notification Parser scans freelist pages and labels what it finds; read recovering deleted Windows notifications for how to evaluate those rows.