Skip to content

Avoid integrity checks after unclean exit, and attempt database repairs harder

Carlos Garnacho requested to merge carlosg/tracker:wip/integrity-checks into master

From the main commit:

core: Refurbish integrity checks, and attempt database repairs

Currently, our integrity checks are both too eager and insufficient.
We will trigger these checks every time the TrackerSparqlConnection
was closed uncleanly (i.e. the process terminating before it has
a chance to be closed), and on the next restart we will perform an
integrity check, but possibly will not fix the underlying issues.

Performing integrity checks but no attempts to repair evidently
falls short, and in times of filesystem journaling and write-ahead
logging the chances of a database corruption just because of an
unclean exit are pretty much non-existent. This behavior was added
long ago when Tracker did run on Nokia devices and olden days' SD
cards, but does not make sense nowadays.

Change this corruption/error handling, so that:
- Any SQLITE_CORRUPT error found does result in the database being
  tagged with a .meta.corrupt hidden file.
- On the next restart, the existence of this file is checked. If
  it does exist:
  - The "REINDEX" SQLite command will be issued to reconstruct
    all database indexes.
  - The content in FTS5 tables will be reconstructed from the
    external content (this was already done).
  - The "integrity_check" pragma is issued, and an initialization
    error is raised if there are remaining errors.

This will avoid the expensive integrity checks and slow startup
times that happened just because a process using Tracker terminated
unexpectedly, and since many types of database corruption come from
inconsistent indexes, we will have better guarantees to get the
database repaired without interaction.

Merge request reports