这是一个用于搜索文件（类似grep）的CLI工具，它不使用操作系统内核来读取文件，而是直接读取你的磁盘。它几乎没什么实际用途，但非常酷。
这只是大约1500行C代码，它：
/dev/rdisk*）时需要sudo；搜索镜像文件无需提升权限sync 调用）但同时：
read() 路径，而是直接 pread 块设备对于真正快速的文件搜索，请查看我的项目 fff——它显著超越ripgrep且无需sudo。
在Linux上，大多数字文件系统都容易实现
这是最容易支持的文件系统：它是一个原地写入的日志型文件系统（非写时复制），因此大多数情况下是ffs的最佳选择。有时你可能会注意到ffs无法看到某些文件的最近更新，这可能是由于内核将最近的更新缓存在内存中并延迟写入磁盘。你可以使用以下命令强制同步：
sync
B树文件系统复杂得多，是一种更高效的存储方式，并且附带一个额外的限制：
当文件系统中的任何文件被更新时，整个超级块也需要更新，这意味着如果ffs读取了超级块（高层B树），随后内核更新了树，那么整个读取就会失效。
可以通过 fsfreeze 或创建一个单独的分离卷来绕过这个问题。
APFS是苹果实现的专有文件系统，已被逆向工程并在本项目中支持，但苹果显著增强了其安全策略。
如果不禁用SIP，你将无法在主磁盘上运行ffs
SIP——系统完整性保护——是一项特殊的安全功能，即使作为root用户也禁止对主磁盘超级块的任何访问。即使使用sudo也无法绕过；你必须禁用该功能（如果你使用了像yabai这样的项目，可能已经禁用了）。
有一种方法可以在不接触主磁盘的情况下测试苹果文件系统上的ffs——你可以直接搜索原始的 .dmg 文件而无需任何提升权限（是的，应用安装程序就是分离卷）。使用ffs，你不需要挂载任何东西，只需提供卷的原始字节路径以及文件系统类型：
ffs "<查询>" /path/to/volume.dmg apfs
由于ffs直接读取字节，你可以用它搜索任何分离卷而无需将其挂载到文件系统。例如读取 .iso 或 .dmg 文件。
这是最有趣的部分——ffs无法访问VFS/内核文件系统缓存。这就是为什么它在较小（或已缓存）目录上会更慢，但一旦缓存耗尽，内核不得不去读取实际磁盘状态时，它会逐渐变快。
为什么？恰好是为了证明在某个点上内核VFS会成为开销。
以下是在btrfs挂载驱动器上比较 ffs 和 ripgrep 的搜索结果。注意 ripgrep 使用了更先进的基于SIMD的匹配器和文件遍历器，而ffs只是大约1800行C代码。
[repos — 631k个文件]
ffs |#### | 5.505s
rg |### | 4.813s
[dev — 1.50M个文件]
ffs |############ | 18.413s
rg |################# | 25.673s
[home — 3.25M个文件]
ffs |######################## | 36.205s
rg |##################################################| 74.690s
用于ripgrep的标志为 -F --no-heading -H -n --no-ignore --hidden --one-file-system --no-messages——这使其输出与ffs相同的结果。
编译项目只需要 libzstd（用于btrfs）、openmp（在你的pkg-config中），然后只需：
make ffs
ffs --help