- 主题:linux中是不是没办法有everything那么快的搜索？
这个远不如everything。
【 在 zqzz002 的大作中提到: 】
: locate
: 发自「今日水木 on iPhone SE」
--
FROM 114.246.239.*
最奇葩的every thing还免费
【 在 chunhui (北瓜) 的大作中提到: 】
: 搜了一下，everything用到了ntfs的mft表。这里面有所有的文件名。所以它找文件名特别快。而且mft这个表是ntfs的内部结构。其他文件系统没有。而且windows还提供了读写文件系统内部结构的api。这就有点不好搞了。linux下的文件系统是不是没有类似的结构可供读取？
: --
: 要把想你的心情收敛 我把门窗关严 但五彩的烟花 却把天空照映成你的笑脸
: 要把想你的心情收敛 我独自走在河边 但倒映在水面的灯火 却让河水起了波澜
--
FROM 39.144.39.*
我更好奇这么多年了，这方法ms自己的文件搜索为啥不用
--
FROM 114.246.239.*
every thing貌似有企业版本收费。反过来想，如果其他平台有这种机制，every thing早就移植过去了。
【 在 freyoneby 的大作中提到: 】
: 最奇葩的every thing还免费
--
FROM 114.240.69.*
不知道，可能微软觉得这种方式不是常规接口。
【 在 tower6 的大作中提到: 】
: 我更好奇这么多年了，这方法ms自己的文件搜索为啥不用
--
FROM 114.240.69.*
linux下面有locate，这个要建索引。
建索引主要是慢，其他也没啥麻烦的
【 在 chunhui 的大作中提到: 】
: 其他分区没有mft的情况下。初次扫描不提。
: 其他分钟它自建的索引，做起来也是非常非常麻烦吧？我自己琢磨着，如果维护的是文件名--路径索引，至少也得维护一个B树来存储路径。
: 否则就没办法处理修改路径名的情况，比如：
: ...................
--
FROM 101.229.188.*
还是不如everything反应快。差一截。
【 在 lvsoft 的大作中提到: 】
: linux下面有locate，这个要建索引。
: 建索引主要是慢，其他也没啥麻烦的
--
FROM 114.240.69.*
搜狗开源过词库
【 在 DreamDreams 的大作中提到: 】
: 显然不是我 做的
: 工程浩大，这东西是 全文检索，比 仅只 文件名可 厉害 太多了
: 唯一不足之处，是他的 索引 引擎xapian， 中文分词做的 不好
: ...................
--
FROM 114.247.175.*
不光要词库，还要分词算法。
【 在 laputa2013 的大作中提到: 】
: 标 题: Re: linux中是不是没办法有everything那么快的搜索？
: 发信站: 水木社区 (Tue Jun 10 17:40:16 2025), 站内
:
: 搜狗开源过词库
:
: 【 在 DreamDreams 的大作中提到: 】
: : 显然不是我 做的
: : 工程浩大，这东西是 全文检索，比 仅只 文件名可 厉害 太多了
: : 唯一不足之处，是他的 索引 引擎xapian， 中文分词做的 不好
: : ...................
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 114.247.175.*]
--
FROM 61.51.75.91
spotlight会把索引藏在每个卷的根目录的隐藏子目录里
【 在 stany 的大作中提到: 】
: Master File Table（MFT）和USN Journal
: ntfs文件系统，他所有文件修改会在usn journal日志体现。everything监听压力很小。
: 其他文件系统可没有这种日志给你提供服务，系统的文件索引也需要分析。
: ...................
--
修改:tgfbeta FROM 60.24.248.*
FROM 60.24.248.*