acid-state-0.16.1.4: Add ACID guarantees to any serializable Haskell data structure.

Safe Haskell | None
Language | Haskell2010

Data.Acid.Repair

Synopsis

- repairFile :: FilePath -> IO ()
- repairEvents :: FilePath -> IO ()
- repairCheckpoints :: FilePath -> IO ()

# Documentation

repairFile :: FilePath -> IO () Source #

``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.

repairEvents Source #

Arguments

:: FilePath | Directory in which the events files can be found.
-> IO () |

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.

repairCheckpoints Source #

Arguments

:: FilePath | Directory in which the checkpoints files can be found.
-> IO () |

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.