Ignore rules
What never enters the index, the three sources of rules, managing them from any interface, and what changing one costs.
If a file you expected is missing from the results, the ignore rules are the first place to look.
Why anything is skipped
A good part of the files on a machine are never searched for. Build output, package caches, .git objects, node_modules — putting those in the index costs twice: the index grows, and the results fill with noise. In one measured case the roots held 4,786,967 files and target/ alone was 2,087,642 of them — 83% of the difference.
So Scour ships with a set of built-in rules. But this should be your decision, so every one of them can be switched off.
Three sources, shown separately
| Source | Where | Removable |
|---|---|---|
| Built in | in the code, 21 rules | no, but they can be switched off |
| config.toml | ~/.config/scour/config.toml |
lines you wrote; Scour never writes to this file |
| Added | added from an interface, kept beside the index | yes |
Scour does not write to config.toml. The reason is simple: putting that file through a serialiser would delete your comments and your notes.
The shape of a rule
| Form | Means |
|---|---|
dir:node_modules |
every folder with this name, wherever it is |
file:desktop.ini |
every file with this name |
path:/var/cache |
everything under this path |
allow:target/release |
a sequence taken back out of a rule above |
A rule that starts with a slash is a path; one that does not is a name. Nothing is guessed in between.
Managing them from an interface
Every face has a “what is being skipped” button. The three sources are listed apart, each rule has a switch beside it, and saving takes effect immediately.
Taking effect means two things, and without both a rule does nothing: the rules are changed behind the lock and every live watcher is retuned. Without the second, a scan sweeps the tree and the watcher puts it all back under the old rule.
What changing a rule costs
There are three prices, and which one you pay depends on what you changed:
| Change | What happens | Measured |
|---|---|---|
| A rule added or switched on | the index is walked, matches deleted — no disk | 2.1 s / 2.25 M rows |
A path: rule switched off |
only that subtree is scanned | depends on the tree |
A dir: / file: rule switched off |
a full scan, unavoidably | depends on the file count |
The third is unavoidable because the rule applied everywhere; the only way to know where it left files is to look.
Why there is no count
No rule shows “how many files this skipped”, and that is deliberate: a file a rule throws away is, by definition, not in the index. Showing the number would mean counting something that is not there — which means walking the disk.