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.

Index: updating the file list without hashing

Each vault card has an Index action alongside the normal scan. It updates the file list only — new, moved and missing files — without hashing anything.

Because it doesn’t hash, an index pass cannot detect corruption. Use it when you want a fast inventory refresh after adding or reorganising a lot of files, and let a normal scan do the verification. A file added by an index pass is recorded but not yet verified; the next full scan hashes it.

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. Happens on any case-insensitive filesystem — every normal Windows volume, and on Linux or macOS when a vault sits on a network share, exFAT, or another mount that ignores case
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
DIR_EXCLUDED	A folder inside the vault was skipped for a reason you didn’t choose — a machine-managed tree such as Windows AppData or Linux ~/.cache, a junction or symlink, or a system location. Recorded so nothing is left unprotected without you knowing. Folders you excluded yourself via Skip folders, and folders starting with a dot, are not listed here. Reported when the set of skipped folders changes, not on every scan

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.
• If the PC or FileGriffon was off when a scheduled scan’s time came, it isn’t skipped — it fires as soon as FileGriffon is next running past that slot’s start time, then resumes its normal daily/interval cadence from there. It’s also never delayed for exceeding it, either — the vault just waits for its own next slot to open the following day/interval, it does not “catch up twice.”
• If several vaults become due at once (a common case after the PC was off for a while), they don’t all start together — see Simultaneous scans below.

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 within a single vault’s scan — there’s no 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.

Simultaneous scans (Settings → Advanced) controls how many different vaults FileGriffon works on at the same time — 3 by default. Two vaults that share a physical drive are always handled one at a time regardless of this setting, since running them together makes a mechanical drive slower, not faster, by forcing it to seek between two working sets. Vaults on separate drives can run in parallel up to this limit. If a manual scan would exceed either rule, FileGriffon shows a warning naming the conflicting vault, with the option to start anyway.

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.