pub fn watcher<F: EventHandler>(handler: F) -> Result<RecommendedWatcher>Expand description
Build the platform watcher every blit watch goes through.
Identical to notify::recommended_watcher but for one setting:
Config::default() turns symlink following on, and notify’s inotify
backend re-WalkDirs a subtree on every IN_CREATE/IN_MOVED_TO that
carries ISDIR (notify 8.2 src/inotify.rs). A recursive watch on a
worktree that contains a pnpm node_modules — where every package is a
symlink into .pnpm/, so the same real directories are reachable under
many paths — or a .direnv linking into the nix store therefore walks a
tree several times its real size, and re-walks it per directory created
anywhere inside. Measured on this repo: 9.7k real directories, 92k when
following, and four such event loops pinned four cores indefinitely.
Cost is not the whole argument, because not following also changes what
is covered. A recursive sync enumerates a symlinked directory under the
link’s own path (docs/design/fs-watch.md § Links), and notify’s walk
yields a symlink as a symlink when it is not following, so filter_dir
drops it and no descriptor covers those aliased paths: an edit under one
is hinted at the target’s real path — which the sync sees only when that
target is itself inside the root — and never at the alias.
Following did not reliably cover them either. inotify_add_watch returns
the same descriptor for an inode already watched, and notify keys its
descriptor→path map on that descriptor, so arming both a pnpm alias and
its real path left whichever the walk reached last reporting for both, and
unwatching either dropped both. The choice is therefore between one stable
rule and an arming-order lottery that could strand the real path, not
between coverage and none. The status engine never reported on the aliases
at all: it asks git, which follows the index.