Data.Acid.Repair

repairFile path will truncate the entries in file until there are only valid entries (if a corrupted entry is found, then the rest of the file is truncated).

The old file will be copied to path.bak (or path.bak.1, etc… if the file already exists).

repairFile tries very hard to avoid leaving files in an inconsistent state: the truncated file is written in a temporary file, which is then moved into place, similarly copies are performed with moves instead. Still this is not fully atomic: there are two consecutive moves, so repairFile may, in case of crash, yield a state where the path.bak file is there but no path is there anymore, this would require manual intervention.

Repairs the WAL files with the following strategy:

• Let f be the oldest corrupted file.

• All files older than f is left untouched

• f is repaired with repairFile

• Old files younger than f is dropped (and saved to path.bak, or `path.bak.1`, etc…)

In other words, all the log entries after the first corrupted entry is dropped. The reasoning is that newer entries are likely not to make sense after some entries have been removed from the log. This strategy guarantees a consistent state, albeit a potentially old one.

Repairs the checkpoints file using the following strategy:

• Every checkpoints file is repaired with repairFile

Checkpoints are mostly independent. Contrary to repairEvents, dropping a checkpoint doesn't affect the consistency of later checkpoints.