Scanning & Detection

How a scan works

Every scan has two phases:

1. Sync — walks the vault’s files and reconciles them against the database using a cheap “head hash” (a fast partial hash used to detect changes and matches without hashing the whole file). This is where NEW, MOVED, and MISSING files are identified.
2. Hashing — computes/re-verifies full-file hashes, up to a size budget (either your Fixed-GB session size, or Auto, which spreads a full recheck of the vault across roughly a 30-day cycle). This is where INITIAL_HASH, VERIFIED, and CORRUPT are determined.

Event types

Event	Meaning
NEW	File wasn’t seen before, added to tracking
MOVED	File matched (by size + hash) against a file missing earlier in the same scan — treated as a move/rename, not a separate delete+add
MISSING	File that was previously tracked is no longer found
INGESTED	File brought under tracking (e.g. first scan of a pre-existing tree)
CASE_RENAME_MERGED	Filename changed only in case (Windows-specific)
INITIAL_HASH	First full hash recorded for a file
VERIFIED	Full hash re-checked and matched — file is intact
CORRUPT	Full hash re-checked and did not match — file content changed unexpectedly
RESCAN_ERROR	Scan couldn’t read/hash the file (permissions, I/O error, etc.)
ACCEPTED	You told FileGriffon to accept a file’s current state as the new baseline (e.g. after an intentional edit)
RESTORED	A file was repaired/restored via the Restore Assistant — see Parity Protection

Each vault also has a hash mode, set when the vault is created: Protected (HMAC-keyed hashes, default) or Raw (plain XXH3-64). This doesn’t change what gets detected, only how hashes are stored — see Security & Encryption.

Important: move detection is per-scan

MOVED matching happens by comparing files that disappeared and files that appeared within the same scan pass. If a file moves in one scan and you don’t notice/rescan for a long time, or if it moves across scans in a way that doesn’t overlap a single sync phase, FileGriffon may record it as a MISSING + NEW pair instead of a clean MOVED. This is a known, current limitation — not a bug you need to report.

Scheduled scanning

Each vault can run in manual or scheduled mode:

• Set a start time (hour:minute) and an interval (e.g. every 24 hours for daily, every 168 hours for weekly).
• A scheduled scan fires once the clock passes the start time and enough time has passed since the last scan (or since you last changed the schedule, whichever is more recent — so you don’t have to wait out an old interval after editing).
• The Dashboard shows a single “Upcoming: {vault} at HH:MM” strip for the soonest scheduled scan across all vaults (only shown when nothing is currently scanning).
• Every scan, manual or scheduled, is tagged so Scan History (under the Events page) can tell them apart.

Note: parity catch-up and the missing-file cleanup sweep both only run after a scan completes. A vault left permanently on “manual” and never rescanned won’t get automatic parity catch-up or missing-file cleanup — run it, or switch it to scheduled.

Performance & resource usage

FileGriffon hashes files sequentially, one at a time, at full speed — there’s no built-in throttling, background-priority mode, or “pause during heavy use” setting yet. Expect noticeable disk I/O (and some CPU for hashing) for the duration of a scan, especially the first one.

The first scan of a vault is the slowest, since every file needs a full hash. After that, most scans are much faster: the sync phase’s head-hash check is cheap, and full re-hashing is spread out — by default, Auto mode targets rechecking a vault’s entire contents roughly once every 30 days, splitting that work across however many scans happen in that window. A Fixed-GB session size, if you set one instead of Auto, takes priority over that calculation.

If a scan is inconveniently slow on a large vault, consider running it on a schedule during hours you’re not using the machine, rather than frequent manual scans.

Where to review results

• Events → File Events: filterable by vault and event type, with free-text search.
• Events → Scan History: cross-vault, paginated list of past scans.