Skip to main content

Module freshness

Module freshness 

Source
Expand description

The freshness sweep (spec/sync/README.md §4.3): the file_stats cache against a filesystem snapshot — as a pure plan (sweep_plan) and as the I/O around it; read-only disk drift; the cache rebuild.

Structs§

CacheRow
A file_stats row.
DiskDrift
How the database disagrees with the disk (§4.3 “Disk drift”).
DiskEntry
One walked file with its stat.
SweepPlan
The §4.3 decisions over a snapshot.
SweepResult
The checkpoint result plus the scan counters.

Functions§

detect_disk_drift
Read-only: the same cache and snapshot, counted, touching nothing.
file_stats_rows
The cache as the fixtures project it: (path, mtime_ns, size, hash hex) by path.
freshness_sweep
§4.3: plan over the cache and the snapshot, refresh touched-not-edited stats, checkpoint changed ++ deletions at ts (with git_head on the row), refresh the cache for the changed paths and drop the deletions’ rows.
load_cache
The repo’s file_stats rows in row order.
rebuild_file_stats
§4.3 (since 1.1): delete the repo’s rows, then walk the tree and record a row only for a file whose bytes’ hash equals its live doc’s file_hash — the cache may say “known” only about bytes the store already holds. A file with no live doc, or whose bytes differ from what was ingested, gets no row, so the next sweep still sees it as a candidate and drift still reports it. Returns the number of files walked, recorded or not.
record_file_stat
§4.3 step 4 record_file_stat: upsert the fresh stat and hash; a path that vanished meanwhile deletes its row.
snapshot
The walk with each file’s stat (a file that vanished between the walk and the stat is skipped).
sweep_plan
§4.3 steps 1–2 as a pure function: hash_of(path) is called once per candidate, in candidate order.