pub enum CachePolicy {
Auto,
On,
Off,
}Expand description
Whether a request may read and write the snapshot cache.
Three values, because the question a caller has is whether fdu should decide, keep
the cache, or stay out of it. What Auto does depends on the analysis: the planner
reads and writes only where a later request can use what it stores, so the default
never pays for a store that nothing reads. Which paths read and write under each
value is crate::execution::plan’s decision and the cache design’s policy table.
Answering from the snapshot without touching the tree is a separate choice,
query::Delivery::stale_ok, since it changes what the answer promises rather than
what the run stores.
Variants§
Auto
Read and write where it pays for this analysis.
A one-shot metadata report neither reads nor writes: revalidating a snapshot stats
every entry, as a cold walk does, and no later one-shot report reads what it would
write. Content analysis reads and writes the snapshot and its content sidecar,
because the sidecar spares re-reading unchanged files. An open session, a
watch, and a refresh read, revalidate, and write, because the session is itself the
later reader.
A root has one cache path, and its snapshot carries the scan scope that wrote it. A read under another scope normally treats that snapshot as absent and scans cold. The lawful exception is a controls-off request with the same entry identity: it projects a controls-on snapshot into the requested blind scope and never replaces the stronger image with that projection.
Every default request observes .gitignore control state – the one-shot
fdu <dir> and prepare_report, fdu --watch <dir>, and a default open –
so they share one scope: a watch or a report that reads the snapshot, as content
analysis does, starts warm from a session’s snapshot or an On report’s. A request
that turns ScanConfig::read_controls off is a second scope, but every route can
start from a default snapshot by discarding its control tier while loading.
On
Read and write where Auto does, and also write after a one-shot report.
The way to leave a current snapshot behind a one-shot report, for a later
query::Delivery::stale_ok answer or a warm session. A summary that would
otherwise retain nothing builds the index it writes. Reads are the same as Auto’s:
loading a snapshot that a full revalidation then re-stats costs more than a cold
walk, and caching never changes an answer, so there is nothing to gain by forcing it.
Off
Ignore any snapshot and leave nothing behind.