Cardinal: macOS 的快速文件搜索（已开源）

下载了，来试一试。

体验不错，略微有点卡顿但是可以接受。

我此前一直用的 Alfred 的 find 命令来替代 macOS 的 Everything ，和楼主的软件使用体验大差不差。

@Mangozhen 非常棒的一个 APP ，确实有 Everything 那个味儿了。初步体验了一个小时，有以下反馈：

1. 初始化要的时间比较长，我这边大约 400 万个文件，花费了差不多 45 分钟来建立索引；
2. 当前版本似乎不支持后台运行。推出后立即进入，会卡顿一下（大约是更新索引）。
3. 特别想要能够自动进行关键词匹配，而不是完全匹配搜索。

支持一下

感谢反馈～
> 初始化要的时间比较长，我这边大约 400 万个文件，花费了差不多 45 分钟来建立索引；
这个还比较奇怪，正常不会有这么慢，我的电脑 700 万个文件应该是 11 秒索引完。有插存储卡之类的东西嘛。
> 当前版本似乎不支持后台运行。推出后立即进入，会卡顿一下（大约是更新索引）。
是加载磁盘里的缓存。
> 特别想要能够自动进行关键词匹配，而不是完全匹配搜索。
是说分词+模糊匹配嘛

下载了，star 了，支持一下

下载支持

@ldm0 对的。在 Spotlight 上，我只需要舒服“A B”，会自动帮我把包含“A”和“B”两个关键词的文档抓出来（包括文档内容）。

这个功能我真的离不开。因为很多时候我都是靠记忆的关键词来检索很久没用的文档。这也是为什么我至今一直使用的 Spotlight ，而没有使用其它类似的工具。

我的索引也很慢，看了下，好像是在检索 iCloud 云盘的时候，触发了下载。后面能不能增加屏蔽某些目录的功能？

@Mangozhen
> 这个功能我真的离不开。因为很多时候我都是靠记忆的关键词来检索很久没用的文档。这也是为什么我至今一直使用的 Spotlight ，而没有使用其它类似的工具。

这个软件主要提供了文件路径子串搜索（比如匹配"/Applications/Xcode.app/Contents/Developer" 路径中的 ".app/Contents/Develop"）和正则搜索的支持，这也是 Everything 的最核心功能。

如果要实现分词，搜索的能力感觉就不那么“确定性”了，用起来心里会虚虚的，和设计的初衷有些差别。SpotLight 可能会出现有某个文件但是搜索不到或者搜索不全的情况。Cardinal 和 SpotLight 的最主要差别就是其用起来的感觉是“确定性”的，能搜到就是有，搜不到就是没有。

比如说我开发过程会产生一些细碎文件，SpotLight 在这种场景下更新索引总是不够实时，容易找不到文件，Cardinal 就 100%能找到，只要存在于文件系统上的文件都不会丢失。

因为面向的需求不一样，所以形态和实现都会有差别～

@duxiansen 这个我操作一手。检索 iCloud 应该不会下载（因为只是 readdir)，应该是缩略图获取才会触发。

这个我用 OneDrive 的时候发现了类似的情况，之前在代码里加了判断。我本地测试一下 iCloud 。

star 支持一下

@duxiansen https://github.com/ldm0/cardinal/releases/tag/v0.1.1 发了个新版，可以再试试看～

这修复的效率真高。试了下，现在索引很快了

没有排序选项吗？恳求加 feature

@Heanes 由于 APFS 的 lstat 接口太慢了（被 NTFS 暴打），没有办法在构建索引时全量获取文件 metadata 。如果苹果不优化的话，没有办法全量排序。因此折中提供了一个 events panel （里面有最新更新的文件列表）

但是搜索结果的排序我会加下（比如搜索结果小于 1w 个时可以根据 path/mtime/ctime 排序），这个在 todo list 上。

这个厉害了，能搜 smb 文件，虽然还比较慢

真好用，能否增加目录屏蔽功能，很多目录其实不需要索引。

@clementewy 可以～晚上下完班加一手

已经放弃 Intel 版本的了吗？

太棒了，晚上回去用起来了再来反馈/div>

用起来很好,希望有个像 Alfred 的 in 功能,可以匹配文本中的字符串

@rainfox 我现在手上没有 Intel 的机器，不好测试。我找个虚拟机看看

牛啊大佬，正好如快的 mac 的文件搜索还没实现，有空学习一下，让如快支持下 mac 的文件搜索。

学习一下，先给一个 star

小星星给你

加颗星

太支持了，不得不 star 了

感谢分享！！ 棒呆！

围观

太强了，已经在用了，很好用

能加个英特尔版本的吗

@xlpxx @rainfox Intel 版本来了~ https://github.com/ldm0/cardinal/releases/tag/v0.1.2

已 star

@ldm0 intel 版本，索引太慢了，半个小时了，还在索引

索引很慢，，上面也不少人说慢，，可以弄个类似索引开关 debug 看看正在索引什么呢 再或者以文件夹做计时器 大于几百毫秒或 1 秒的显示一下 我打开几十秒确实索引了 1000 多万 但是 1000 多万开始就慢了 1200w 到 1700w 花了七八分钟 还在索引

MacBook Air M4 ，114 万个文件，正在初始化了十多分钟，不知道什么情况

@xxnemesis1 二十分钟了，还在初始化…

正常百万级的文件索引是在 10 秒内完成的。
索引逻辑是并行遍历文件系统（主要是 readdir)，可能是访问某个文件夹阻塞了。
主要问题在于我这边的几台机器，包括我朋友同事的机器索引都比较快无法复现这个问题，目前没有什么头绪。

@xxnemesis1 @prudence @rainfox 有联系方式么，我可以单独出个 debug 包看看什么文件访问卡住了。我的 WX 是 TERNMjMzMzMzMw==

支持，但是我试了好几次，索引实在太卡了，一直没索引完。app store 有一个 profind ，不用索引，速度很快了。

@ldm0 #10 #10 OK 的，也许后面随着 APP 的完善，可以加上一些需求。

@rainfox #35 #35 APPLE Silicon 也是这样。

hi ，如果有可能能否支撑 everything 的 etp 协议，并且能自定义映射到本地的路径。这样就能无缝搜索 winnas 上的文件，并且使用 smb 路径打开了。
谢谢！

确实初始化有点问题，索引到 12,577,071 个文件时就卡住了，从上午到现在卡了一整天没有进展，重启也不能解决问题。

@theo 试试最新版呢，修复了一个索引卡死的 bug https://github.com/ldm0/cardinal/releases/

star 支持，期待后续的开完过程分享

很棒

@Vaspike 补充一句题外话,我自己开发过程中发现, 有`Accessibility`权限的应用能获取采集到的信息是恐怖的, 需要这个权限的应用最好是开源, 其次是你认为放心的公司闭源产品, 其他的最好不用
这个`full disk access`权限目前我还没使用过, 但应该差不多

@Vaspike #48
补充一句题外话,我自己开发过程中发现, 有`Accessibility`权限的应用能获取采集到的信息是恐怖的, 需要这个权限的应用最好是开源, 其次是你认为放心的公司闭源产品, 其他的最好不用; 这个`full disk access`权限目前我还没使用过, 但应该差不多

好用！！！

@Vaspike `full disk access` 在这里的原因是要遍历索引整个文件系统，文件搜索工具都需要这个 level 的权限。
不可能不申请（

@ldm0 #51 哈哈,我不是说不应该申请这个权限, 只是看到授予权限时想到了这件事

请教一下, 这个软件可以集成到 raycast 吗?
跟 raycast 自带的搜索比有什么优势

@devoteever 不太了解怎么集成。
优势是更快，更准，更全（刚刚下载横向对比了一下）。

相当好用，感谢

非常棒
最近发现一个问题，他老占用着我的外挂磁盘，或者安装软件挂载的 dmg ，倒是硬盘退不下来。
软件里面能不能设置个搜索白名单呢。

很好用，已 star ，另外有小建议：
-顶部任务栏的显示托盘图标可以考虑改下颜色（目前是彩色的），建议和系统 UI 保持一致。

感谢作者的制作，使用体验和 everything 基本一样了！

indexing 特别慢，在 180w 左右开始每秒就个位数的往上涨，有 Google Drive 和 SMB 网络位置（局域网），不确定是哪个部分拖慢了进度。。

@nbook 看来是 Google Drive 的问题，把/Users/<user>/Library/CloudStorage 排除掉就正常了

@ldm0 和楼主的项目切磋一下,我的搜索系统 filepulsesoft.com ，过去仅支持 win ，现在已经支持 linux,mac 同时原生支持 x86_64,arm64
同时支持文件名和文件内容索引，支持跨系统跨架构组成集群搜索，搜索结果在集群中排序。
我的 mac 文件比较少，100 万文件 4 秒多完成索引。搜索全部 100 万文件文件名，搜索速度 4 毫秒，截图如下：

@EdgarZhang 新的版本已经增加搜索白名单~

@hkhk366 欢迎切磋～ 一些感受意见：

1. 搜索我看你用的 jwalk-meta （ https://github.com/brmmm3/jwalk-meta ），本身也是也是一个不错的实现，速度和 Cardinal 的 fswalk 是一个量级的：我的电脑上 773 万个文件索引完花费 29 秒钟
2. 4 毫秒是个非常棒的速度！ Cardinal 在 773 万个文件上的全盘搜索速度是 56 毫秒。这其中的主要差别我猜测主要在于文件 metadata 获取和本地 ipc ，Cardinal 会将这两部分包含在搜索耗时之中。
3. 没有找到你的 FSEvent 获取逻辑，可能会在第一次扫描之后索引逐渐过时。

欢迎下载 Cardinal 进行一些横向对比，包括 CPU 占用内存占用，以及功能的丰富程度。欢迎交流～ :D

@nbook 感谢反馈，我研究下怎么处理

@ldm0
Hi
1. 用什么 walk 都一样，没有本质区别，哪个顺手用哪个
2. 我那个 4 毫秒的速度是整个请求速度，从前端发送请求到收到最终结果的完整时间，可能实现有区别，但是没有本质区别，时间复杂度还是在一个量级。

这个东西也没什么优化空间，到极限了，我和你的项目不同是，我为了和 Windows 平台整合在一起，牺牲了一些性能。

这个貌似不支持文件内容的搜索？只支持文件名？

@kanade 支持文件内容的搜索，用 content: filter ，只是不会做文件内容的索引，和 Everything 是对齐的。