- 主题:linux中是不是没办法有everything那么快的搜索？
搜了一下，everything用到了ntfs的mft表。这里面有所有的文件名。所以它找文件名特别快。而且mft这个表是ntfs的内部结构。其他文件系统没有。而且windows还提供了读写文件系统内部结构的api。这就有点不好搞了。linux下的文件系统是不是没有类似的结构可供读取？
--
FROM 111.196.134.*
这个没用过。不知道它啥原理。如果文件系统没有对应的结构，很难达到everything的速度。
【 在 rpk 的大作中提到: 】
: 这个不知道快不快：
: github/cboxdoerfer/fsearch
--
FROM 111.196.134.*
猜测内核模块只能让它更多地截获文件相关信息。但仍然不能达到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.*
其他分区没有mft的情况下。初次扫描不提。
其他分钟它自建的索引，做起来也是非常非常麻烦吧？我自己琢磨着，如果维护的是文件名--路径索引，至少也得维护一个B树来存储路径。
否则就没办法处理修改路径名的情况，比如：
/home/data 路径中有N个文件。用户修改了data变成了：/home/data2
这样原来路径下的所有文件的索引都需要修改。。。
或者维护的是文件名--inode索引。或许可以不用自己维护B树。
【 在 stany 的大作中提到: 】
: everything有自己的索引文件Everything.db
: 不同分区类型创建方式不一样。
: ntfs文件索引在mft，所以只需要监听mft。
: ...................
--
FROM 111.196.134.*
我搜到的也是这么说的。感觉它主要还是利用mft表。否则它这么快就不止限于ntfs。其他文件系统也应该可以非常快。
【 在 stany 的大作中提到: 】
: 百度回答：
: Everything的工作原理主要依赖于NTFS文件系统的Master File Table（MFT）和USN Journal的特性。
: Everything在第一次启动时会扫描整个磁盘，并建立一个索引库。这个索引库是通过遍历NTFS文件系统的MFT表来完成的，MFT表中存储了所有文件夹和文件的名称、路径等信息。通过读取MFT表，Everything能够获取当前磁盘中的所有文件信息，并保存在数据库中。
: ...................
--
FROM 111.196.134.*
厉害。这是你作的？
感觉只是索引文件名，就很复杂。比如我上面说的情况。何况内容了。。。
【 在 DreamDreams 的大作中提到: 】
: 看看我 签名档里 这个
--
FROM 111.196.134.*
我说的就是这个。所以在其他文件系统上，很难实现everything这样的速度。
【 在 stany 的大作中提到: 】
: Master File Table（MFT）和USN Journal
: ntfs文件系统，他所有文件修改会在usn journal日志体现。everything监听压力很小。
: 其他文件系统可没有这种日志给你提供服务，系统的文件索引也需要分析。
: ...................
--
FROM 111.196.134.*
我好奇everything怎么弄这么快的。搜了一下。发现这个东西有相当的难度。还没考虑到全文检索的程度，就够复杂的了。
不过这个东西windows和mac中官方的搜索也做的很一般。有时候你明知道有那个关键词，它就是搜不出来。
【 在 DreamDreams 的大作中提到: 】
: 显然不是我 做的
: 工程浩大，这东西是 全文检索，比 仅只 文件名可 厉害 太多了
: 唯一不足之处，是他的 索引 引擎xapian， 中文分词做的 不好
: ...................
--
FROM 111.196.134.*
mac中也有通知机制 好像是fevents。但没有向windows一样的文件系统底层读写接口。
【 在 DreamDreams 的大作中提到: 】
: Linux下 有inotify/gnotify ， 事件驱动的
--
FROM 111.196.134.*