搜了一下，everything用到了ntfs的mft表。这里面有所有的文件名。所以它找文件名特别快。而且mft这个表是ntfs的内部结构。其他文件系统没有。而且windows还提供了读写文件系统内部结构的api。这就有点不好搞了。linux下的文件系统是不是没有类似的结构可供读取？
--
FROM 111.196.134.*

我的系统装了plocate，但是我很少用。
Deepin倒是搞了一个anything，借鉴了everything的原理，需要用内核模块。

【 在 chunhui 的大作中提到: 】
:   搜了一下，everything用到了ntfs的mft表。这里面有所有的文件名。所以它找文件名特别快。而且mft这个表是ntfs的内部结构。其他文件系统没有。而且windows还提供了读写文件系统内部结构的api。这就有点不好搞了。linux下的文件系统是不是没有类似的结构可供读取？
--
FROM 124.64.19.*

猜测内核模块只能让它更多地截获文件相关信息。但仍然不能达到everything的速度。因为everything是靠文件系统带的存储结构。

如果文件系统没有类似mft的结构，除非plocate fsearch自己构建这种索引。但自己构造这种索引的话，会非常复杂。似乎要镜像一个文件系统的B树。或许在内核中可以避免自己镜像B树？

不清楚了。
【 在 ArchLinux 的大作中提到: 】
: 我的系统装了plocate，但是我很少用。
: Deepin倒是搞了一个anything，借鉴了everything的原理，需要用内核模块。
--
FROM 111.196.134.*

我搜到的是说它直接读取的ntfs的mft表。
如果everything也是通过自己建索引的方式，那其他文件系统也可以实现。没理由只在ntfs下才这么快。---- 这样的话，问题就是：它用的啥索引方式？为啥能这么快？

我只是好奇随便搜了一下。everything。不知道有没有更靠谱的资料介绍？
【 在 stany 的大作中提到: 】
: everything针对fat32也能用。相当于先建索引，后实时监控。
: 理论上linux模拟相同的应该没问题。
--
FROM 111.196.134.*

百度回答：
Everything的工作原理主要依赖于NTFS文件系统的Master File Table（MFT）和USN Journal的特性。

Everything在第一次启动时会扫描整个磁盘，并建立一个索引库。这个索引库是通过遍历NTFS文件系统的MFT表来完成的，MFT表中存储了所有文件夹和文件的名称、路径等信息。通过读取MFT表，Everything能够获取当前磁盘中的所有文件信息，并保存在数据库中。

NTFS文件系统有一个特性，即USN Journal，它记录了所有对文件系统的修改操作。Everything通过监控这个日志文件，实时更新索引库中的信息，从而实现对文件修改的监控。

在文件查找方面，Everything使用字符串匹配算法从之前建立的索引中进行匹配，快速显示文件名称和路径。这使得Everything的搜索速度非常快，尤其是在处理大量文件时，相比Windows系统自带的搜索工具，其效率显著提高。
【 在 stany 的大作中提到: 】
: everything有自己的索引文件Everything.db
: 不同分区类型创建方式不一样。
: ntfs文件索引在mft，所以只需要监听mft。
: ...................
--
FROM 27.11.145.*