GitHub Hot Board

GitHub Hot Board · Repo-Archiv

noahdunnagan/fsearch

Whole-disk file search for macOS: fuzzy names, typo tolerance, indexed content grep. ~1 ms over 8M files. (Diese Beschreibung stammt vom Repository.)

Datenstand October 26noahdunnagan

Bestplatzierung

#114

Steile Kurve

2.2K

Sterne total

139

Forks total

5

Ranking-Tage (30 T.)

5 Tage auf Boards · +16 Sterne in 30 T. · ~+3/Tag5 Tage in Folge

ProjektstatusLizenz: MITLetzter Push: October 12Offene Issues (inkl. PR): 7

Seit 2026-10-25 erfasst; unbekannt = noch nicht erhoben

Badge in dein README · noahdunnagan/fsearch[![Badge in dein README](https://git.vaiox.xyz/api/badge/noahdunnagan/fsearch.svg)](https://git.vaiox.xyz/de/repo/noahdunnagan/fsearch)
<a href="https://git.vaiox.xyz/de/repo/noahdunnagan/fsearch"><img src="https://git.vaiox.xyz/api/badge/noahdunnagan/fsearch.svg" alt="Badge in dein README" height="20"></a>

Projektdokument

FSearch

Whole-disk file search for macOS: names in about 0.1 ms, typo-tolerant, plus indexed search inside files. A CLI with a small daemon, a Rust crate, or an MCP server for coding agents.

cargo build --release && ./target/release/fsearch install   # -> ~/.local/bin/fsearch
fsearch fsearch main              # find files by name
fsearch 'ext:rs grep:apply_dir'   # search inside files

Or skip the Rust toolchain with a release build for Apple Silicon:

curl -L https://github.com/noahdunnagan/fsearch/releases/latest/download/fsearch-aarch64-apple-darwin.tar.gz | tar xz && ./fsearch install

Speed

M4 Mac mini, a home holding the Linux or the Chromium source tree, vs the previous version (b88f4e9). Medians; Linux / Chromium.

before now
right file first, name search 83% / 86% 93% / 97%
right file first, two typos 11% / 15% 74% / 93%
find a file by name 0.045 / 0.10 ms 0.054 / 0.12 ms
an edited file greppable 2.1 s 1.3 ms
a rename or delete visible 45 / 47 ms 18 / 15 ms
first run, a name in a folder 7.8 / 7.8 s 0.18 / 1.2 s
first run, every match in the tree 10.9 / 12.2 s 2.4 / 10.8 s
files grep can search (rg's own set) 96% / 92% 99.9% / 99.8%
grep, first page 0.29 / 0.48 ms 0.33 / 0.65 ms
index on disk 503 / 893 MB 309 / 600 MB
peak memory while indexing 1.13 / 1.37 GB 0.77 / 0.94 GB
daemon memory 19 / 100 MB 21 / 35 MB

The index is a third smaller while holding a third more text: one 3-bit filter per file instead of two, compressed posting lists and paths, and bit-packed name arrays read in place. Grep's first page reads a few more files for it, and the deeper typo search costs a little on names.

Queries

fsearch 'readme in:~/Developer'          # inside a folder
fsearch 'type:image size:>5mb mtime:<7d'
fsearch 'ext:rs regex:fn\s+\w+_dir'      # regex inside files
fsearch 'sym:apply_dir'                  # where it's defined
fsearch 'src/**/*.{c,h} !test/ init'     # globs, in or out
fsearch 'git:modified in:~/Developer/app'

Words are fuzzy and forgive a typo at any letter, two in words of 8+ (mian.rs finds main.rs); several words can spell one name. Accented names match however they were stored. Also 'exact, ^prefix, suffix$ and !exclude. Filters: ext: type: kind: in: size: mtime: re: path: grep: regex: sym: limit: and git: (modified staged untracked clean tracked ignored conflict). Content search is smart-case, and regexes match within a line, as in ripgrep.

What grep covers

Text files up to 1 MB, and up to 10 MB inside git repos, minus what git ignores. It leaves out lockfiles, JSON of 100 KB and up, minified or bundled assets, linked git worktrees (their main checkout is indexed), and build-output folders outside repos. To leave out more, list folders in ~/Library/Application Support/FSearch/content-skip.txt, one per line (~ and # comments work). Names are always indexed, and a grep inside a file you name still reads it.

Full Disk Access

From a terminal with Full Disk Access it indexes everything. As a login item (fsearch install --login), grant ~/.local/bin/fsearch access in System Settings > Privacy & Security, again after each rebuild. Without access it skips protected folders instead of prompting.

API

JSON lines over ~/Library/Application Support/FSearch/fsearch.sock, or fsearch stdio:

{"q": "fsearch main", "limit": 20, "offset": 20}
{"op": "grep", "pattern": "apply_dir", "in": "~/Developer", "context": 2}
{"q": "main.rs", "boost": true, "near": "~/Developer/app/src/lib.rs", "git": true}
{"op": "open", "path": "~/Developer/app/src/main.rs"}
{"op": "recent", "in": "~/Developer/app"}

open tells it what you opened; "boost": true ranks those higher for a while, near favors files close to the one you're in, and recent lists what you worked on lately. "git": true adds each hit's git status.

For coding agents, fsearch mcp is an MCP server on stdio with find_files, grep and multi_grep.

Or link the crate:

let engine = fsearch::Engine::start(fsearch::Options { dir: fsearch::default_dir(&home), home: home.clone(), skip: None })?;
let hits = engine.search(&fsearch::Query::parse("fsearch main", &home)?)?;

An app and the CLI share one index: the first process owns it, the rest follow.

How it works

  • Crawls the disk once with getattrlistbulk, then follows FSEvents: changes show up in about 15 ms, and a restart replays only what changed. On a first run, a search in a folder indexes that folder first.
  • Names live in one mmap'd file, folder by folder, so in: is a range. A bitmap of each name's letters rules out most names before scoring.
  • Content search is a trigram index plus a per-file filter, so a search only reads files likely to match. Identical files are indexed once, and deleted files' entries are compacted away. Matches are read fresh from disk; files edited since the last index sync are read directly.
  • The daemon runs with malloc's space-efficient mode, so it gives memory back when idle.

Aktuelle Platzierungen

  • 114

    Steile Kurve

    2.2K Sterne · 139 fork · Sterne pro Tag

    Steigung →

Verlauf der letzten 30 Tage

Kumulierte Sterne

Platzierungsverlauf

Tägliche Sterne

Rangnachbarn auf demselben Board · Steigung

← Zu den Boards