FSearch is an open-source whole-disk file search for macOS, in Rust

Opening a terminal and finding any file on a Mac by name in 1.3 milliseconds, with a typo forgiven, is the task FSearch wants to replace Spotlight for.

Noah Dunnagan released FSearch under MIT on GitHub, and the repository collected 347 stars on its first day. The README publishes a benchmark against the fff search tool on the same Mac, on the Chromium checkout and the Linux kernel, and names where fsearch wins and where it ties.

What it does

The tool runs as a small daemon with a command-line front end. The README names an M4 Max with 7.7 million files on disk, and reports median latencies of 1.3 milliseconds to find a file by name across the whole disk, 9 milliseconds to search inside files, 0.1 seconds between a new or renamed or deleted file and that file showing up, and 20 seconds for the first disk crawl. Daemon memory sits between 30 and 135 megabytes.

Queries are more than names. The README lists filters for extension, type, kind, directory, file size, modification time, path regex, grep inside files, regex inside files, defined symbols, and limits. Words are fuzzy, and words of five or more letters forgive one typo, so a search for mian.rs finds main.rs.

The published benchmark against fff

The README compares FSearch to the fff tool on Chromium's 509,000 files on the same Mac, and gives one measured number per row. Finding a file by name is 1.1 milliseconds for FSearch against 13.8 milliseconds for fff. Searching inside files is 5.6 milliseconds against 53. The typo still finds the file first 98% of the time for FSearch against 88% for fff. Memory is 50 megabytes for FSearch across the whole disk against 358 megabytes for fff on that folder. On the smaller Linux kernel, with 96,000 files, name search is a tie and FSearch wins the rest.

The README names its caveats. FSearch skips some file types and build/ and vendor/ folders, so the README says fff indexes 9% more of the file content on that comparison. All of these numbers are the author's own, measured on his machine. They have not been independently reproduced.

How it is built

FSearch crawls the disk once with getattrlistbulk, then stays up to date through FSEvents. A restart replays only what changed. File names are stored in one memory-mapped file laid out folder by folder, so a directory filter is a range lookup rather than a scan. Content search uses a trigram index of text files, and matches are read fresh from disk at query time. One index serves both the command line and any app linking the Rust crate: the first process to start owns the index and the others follow it. A terminal with Full Disk Access indexes everything, and installing it as a login item requires giving the binary its own grant in System Settings.

Source

• noahdunnagan/fsearch, GitHub