Summary
ripwire writes its index cache under $TMPDIR. On systems where TMPDIR points at a small, separately-budgeted volume, the cache accumulates until that volume is exhausted — and because the artifacts are never pruned, the pressure is permanent rather than transient.
Version: ripwire 0.6.1 (Release, GNU 13.3.0, built_from=30f14a274)
What I measured
Running under Claude Code, which sets TMPDIR to a dedicated scratch volume per session:
$TMPDIR/ripwire/<2-hex>/ripwire-<16-hex>-lean.bin
6 files, 5 of them ~24MB each = ~117MB
mtimes spanning a single ~7-hour working session
Each distinct repository state appears to produce its own -lean.bin, keyed by a content hash. Over one long session across a few branches, five accumulated. Nothing removed the earlier ones — they are still there after the states they describe are gone.
On that host the scratch volume is budgeted at 500MB with a warning threshold at 375MB. Ripwire's 117MB alone was 23% of the budget, and removing just those stale caches took total usage from 410MB back to 293MB — i.e. from over-threshold to comfortably clear.
Why TMPDIR is the wrong home for this
A per-repository-state index is a cache: expensive to build, cheap to discard, valuable to keep across runs. TMPDIR is for ephemeral scratch that a process creates and removes within its own lifetime, and on many systems it is deliberately small, tmpfs-backed, or managed by an external janitor that assumes anything inside is disposable right now.
Storing a long-lived cache there gets the worst of both: it is large enough to matter, persistent enough to accumulate, and sitting in the one directory whose supervisor is most likely to delete it mid-use or to start reclaiming other things when it fills.
Suggested fix
The binary already references XDG_CACHE_HOME, so the smallest change is likely to prefer it for these artifacts:
$RIPWIRE_CACHE_DIR if set — an explicit escape hatch is useful for exactly the constrained-TMPDIR case;- else
$XDG_CACHE_HOME/ripwire;
- else
~/.cache/ripwire;
TMPDIR only for genuinely transient intermediates.
A retention bound would help independently of location — an LRU cap on total cache bytes, or eviction of entries whose repository state is no longer reachable. Right now the only bound is how many distinct states a user happens to index.
Impact as seen from outside
The failure is indirect and therefore hard to attribute. On the host above, the scratch volume's watchdog responded to the pressure by evicting idle editor sessions — which reclaimed nothing, because the sessions were not what filled the disk. From the user's side, unrelated work disappeared overnight and the cause was several layers away from the symptom. A cache in $XDG_CACHE_HOME would not have interacted with that supervisor at all.
Happy to test a patch against the same workload if useful.
Summary
ripwirewrites its index cache under$TMPDIR. On systems whereTMPDIRpoints at a small, separately-budgeted volume, the cache accumulates until that volume is exhausted — and because the artifacts are never pruned, the pressure is permanent rather than transient.Version:
ripwire 0.6.1 (Release, GNU 13.3.0, built_from=30f14a274)What I measured
Running under Claude Code, which sets
TMPDIRto a dedicated scratch volume per session:Each distinct repository state appears to produce its own
-lean.bin, keyed by a content hash. Over one long session across a few branches, five accumulated. Nothing removed the earlier ones — they are still there after the states they describe are gone.On that host the scratch volume is budgeted at 500MB with a warning threshold at 375MB. Ripwire's 117MB alone was 23% of the budget, and removing just those stale caches took total usage from 410MB back to 293MB — i.e. from over-threshold to comfortably clear.
Why
TMPDIRis the wrong home for thisA per-repository-state index is a cache: expensive to build, cheap to discard, valuable to keep across runs.
TMPDIRis for ephemeral scratch that a process creates and removes within its own lifetime, and on many systems it is deliberately small,tmpfs-backed, or managed by an external janitor that assumes anything inside is disposable right now.Storing a long-lived cache there gets the worst of both: it is large enough to matter, persistent enough to accumulate, and sitting in the one directory whose supervisor is most likely to delete it mid-use or to start reclaiming other things when it fills.
Suggested fix
The binary already references
XDG_CACHE_HOME, so the smallest change is likely to prefer it for these artifacts:$RIPWIRE_CACHE_DIRif set — an explicit escape hatch is useful for exactly the constrained-TMPDIRcase;$XDG_CACHE_HOME/ripwire;~/.cache/ripwire;TMPDIRonly for genuinely transient intermediates.A retention bound would help independently of location — an LRU cap on total cache bytes, or eviction of entries whose repository state is no longer reachable. Right now the only bound is how many distinct states a user happens to index.
Impact as seen from outside
The failure is indirect and therefore hard to attribute. On the host above, the scratch volume's watchdog responded to the pressure by evicting idle editor sessions — which reclaimed nothing, because the sessions were not what filled the disk. From the user's side, unrelated work disappeared overnight and the cause was several layers away from the symptom. A cache in
$XDG_CACHE_HOMEwould not have interacted with that supervisor at all.Happy to test a patch against the same workload if useful.