• v8.4.0 70886da548

    v8.4.0 Stable

    dpsifr released this 2026-07-15 20:24:48 +02:00 | 31 commits to main since this release

    Downloads
  • v8.3.3 92299f27be

    v8.3.3 Stable

    dpsifr released this 2026-07-15 18:48:01 +02:00 | 35 commits to main since this release

    Downloads
  • v8.3.2 1a3a493c27

    v8.3.2 Stable

    dpsifr released this 2026-07-14 20:57:00 +02:00 | 39 commits to main since this release

    Downloads
  • v8.3.1 d9fa3be648

    v8.3.1 Stable

    dpsifr released this 2026-07-14 19:14:38 +02:00 | 42 commits to main since this release

    Downloads
  • v8.3.0 c40a89e649

    v8.3.0 Stable

    dpsifr released this 2026-07-14 00:21:52 +02:00 | 46 commits to main since this release

    Downloads
  • v8.2.8 7b75f932d4

    v8.2.8 Stable

    dpsifr released this 2026-07-13 22:26:41 +02:00 | 51 commits to main since this release

    Downloads
  • v8.2.7 36d4e80ba2

    v8.2.7 Stable

    dpsifr released this 2026-07-13 21:18:26 +02:00 | 53 commits to main since this release

    Downloads
  • v8.2.6 76843b782e

    v8.2.6 Stable

    dpsifr released this 2026-07-13 19:59:56 +02:00 | 55 commits to main since this release

    Downloads
  • v8.2.5 ffd81ea206

    v8.2.5 Stable

    dpsifr released this 2026-07-12 21:27:01 +02:00 | 66 commits to main since this release

    Downloads
  • v8.2.4 036e56c9f9

    v8.2.4 Stable

    dpsifr released this 2026-07-12 18:21:02 +02:00 | 69 commits to main since this release

    v8.2.4 — 2026-07-12 (restore can no longer destroy the store it's recovering)

    Recovery-safety fix. restore() removed the entire live brain directory and THEN copied the
    snapshot in — so any copy failure left the store destroyed with only a partial copy. The sharpest
    edge: the copy (fs.cp) materialized the holes of sparse mmap blob files, so a snapshot that fits
    on disk could balloon and ENOSPC mid-copy, and the recovery tool would have just destroyed the
    brain it was asked to recover. Reported from a downstream incident's recovery forensics.

    Restore is now non-destructive and crash-resumable:

    • The snapshot is copied into a staging area (_restore_staging/) before any live data is
      touched
      . The copy is sparse-aware — all-zero regions are left as holes, so a store of
      mostly-hole blobs restores at its true allocated size instead of its apparent size.
    • A copy failure (including ENOSPC) removes only the half-written staging area and throws; the
      live store is left exactly as it was.
    • Only after the copy succeeds and a completion marker is fsync'd does an atomic per-entry
      swap
      move the staged data into place — same-filesystem renames that cannot fail for disk space.
    • A crash mid-swap is finished forward on the next open: startup resumes a committed-but-
      incomplete swap, or discards an uncommitted staging area (live data still authoritative).

    No API change — restore(path, { confirm: true }) is unchanged. persist() was already safe
    (hard-link snapshot). Regression (tests/integration/restore-nondestructive.test.ts): a forced
    copy failure leaves live data fully intact, a normal restore round-trips, an interrupted-but-
    committed restore completes on reopen, an uncommitted staging area is discarded, and the sparse
    copy is byte-identical with allocation far below apparent size.

    Downloads