大概05年前后，我觉得所谓的目录管理有条理是个伪命题。因为一个文件你可以按照不同的维度去切割分类，你分的越细越有条理，就越容易遇到另一种非常难检索的维度。

于是我基于fuse做了一个虚拟文件系统，把目录的层级作为搜索关键字，比如cd a/b/c，进入的目录其实就是用a b c作为关键字去搜索匹配后的所有文件。这里因为是关键字，所以顺序就不重要了，cd c/b/a和a/b/c的结果是一样的。也即你可以随心所欲的按照你想要的tag cloud方式去匹配想要的文件。同样的还可以有各种搜索语法。比如直接a/b/c进行的是文件名以及那个文件的所有父目录名的关键字匹配。也可以content:xxx/date=xxx等方式进行包括内容关键字，meta信息等更复杂的匹配。实现好之后，基本上用起来感觉还是像那么回事的。不过文件光找到还不行，还有要能编辑，要能生成新的文件等等问题。比如在content:xxx/目录下创建一个内容只有yyy的文件，或者把符合条件的文件改成不符合条件会产生一系列的矛盾问题。

总之，要完善细化还需要不少后续工作。但我觉得这个基本理路是可以针对这类需求的。

【 在 gnwd 的大作中提到: 】
: 经常打开不同目录的文件，在目录中跳转来跳转去，耽误不少时间。有时候为了目录管理有条理，目录层次还不算浅。
: 但其实这几个月常打开的可能就这几份或者十几份文档。
: 当然可以建一个目录，往里面扔符号连接。不知道有没有别的更好的方法
--
FROM 180.111.50.*

一半是这样，另一半就是用文件系统作为入口。
其实我最初的目标是能快速进入我想要的目录。
比如一个文件我放在a/b/c/d/e/f/g/foo.txt
我直接cd a/g/foo,里面就有这个foo.txt

【 在 hgoldfish 的大作中提到: 】
: 这就是传说中的文档索引？
: kde/windows 都带了全文检索引擎，能够检索指定目录的 word 文档，pdf，图片元数据。是这个意思吗？
: 不过我一般装完 KDE 第一件事情就是关了这货。
: ...................
--
FROM 180.111.50.*

这个问题说的更简单一点，其实就是当年google搞桌面搜索的时候提出的一个问题：
找一个东西，比起在你的本地硬盘里面找，往往是搜索引擎里面找了下载回来更快更简单。

不过当年大家都比较淳朴，还试图用技术去让世界变得更美好...放现在这不是典型的分流行为嘛，在提出的一瞬间就被枪毙了...所以桌面搜索这玩意这么多年了，本质上还是原地踏步。

我大致看了下tagspaces，我觉得这个东西还是不够的，更多的是管理媒体而不是管理文件。
我现在用的文档管理系统也都支持打tag，但我实际上打tag的行为只有1%...并且真正通过tag找到文件的次数更是基本可以忽略...很多时候我需要的找的东西并不会有很好的组织。比如我可能要找某天写的c代码里面的一个片段，我肯定不会为每个c代码去打个tag，我只会为整个项目打tag，而且通常情况这就是项目的文件目录名。

归根结底我们找东西，还是基于2个方法，一个是时间，比如昨天，本周，近期；另一个是脑子里想起的一个关键字，通常就是文件名，多层的父目录名，最后才是文档内含的某个关键字。除非说要找5年前的某个文档，这种根据收藏夹，tag也许还有点价值...所以windows下的everything直接就解决了90%的问题。

而我希望的是一个基于文件系统的搜索引擎，它有足够高的智能，我给出3个信息它就能直接替我进入那个本地目录。理论上在现在的ai能力下这应该是可行的。至于为啥要基于文件系统界面，因为这样的设计足够正交，这套能力可以很容易嫁接到现有的各种工具上。但这个问题的本质，还是搜索结果的准确度上。
【 在 ilovecpp 的大作中提到: 】
: 很多完善的工具了，如tagspaces之类。
--
修改:lvsoft FROM 180.111.50.*
FROM 180.111.50.*

这个也是无关的。
现在基于fuse整个虚拟文件系统界面非常简单，这不是主要问题。
主要的问题还是怎样整个高效又精准的本地搜索引擎。事实上我当时的尝试就是卡在这里。
我的这些想法在2005年的时候我就全部实现了，只是细节问题还有很多，远没有打磨到足够实用的程度。

【 在 zeus2615 的大作中提到: 】
: 在xdg-open外面包一套你的逻辑呢
--
FROM 180.111.50.*

这就是核心问题了。
首先考虑duplication，这个感觉是可以合并的。但编辑文件的时候就又有问题了，因为一份文件在几个目录里面复制几遍完全合理。有的场合是只更新其中一个，有的场合又希望全盘所有副本同步更新，具体要哪个是我说了算的。

其次就是你说的ambiguity问题。结合duplication问题，我不得不对模型进行了一些简化。在你不断cd（也即不断提供更多的搜索关键字）的过程中，返回的结果是从全盘搜索结果的aggregation到一个精确的sub folder的逐步过渡过程。最终在你提供了足够的信息，完全消除歧义之后，你会进入一个确定的folder。这个简化其实是有蛮大的效率损失的，因为进入一个确定的folder并不是最高效的形式，只能说是向可实现性进行的妥协。比如a/b/c/foo.txt和/d/e/a/bar.txt，理想情况下我希望cd a/之后看到的就是foo.txt和bar.txt（然后你在这个目录下创建的新文件该放哪里呢？又是一个头疼的问题）。所以只能妥协到最终会进入一个明确的folder。这样ambiguity问题就简单多了。

但在进入确定的目录之前的虚拟文件夹，里面的文件是各种可能性的聚合。因为可能性非常的多，所以这还不是简单的聚合，还需要分类整理。比如如果你全盘的目录结构很简单就一个/a/b/c/foo.txt，那你cd a就直接就看到foo.txt了。
但如果你还有/d/e/a/bar.txt，那你cd a看到就应该是b/,d/这两个子文件夹，你还需要做出更多的选择才能消除这一层的歧义。

但具体细化之后问题还有很多。比如你第一次cd a能看到foo.txt了，但后面建立了/d/e/a/bar.txt之后，下次你就cd a就有歧义，无法直接看到foo.txt了，这种不确定的变化会打破很多东西。此外在真实文件系统上困难也相当的多。因为真实文件系统里面有很多cache folder，里面存了茫茫多的文件名，正常情况你完全不会关注它，但在这种基于全盘搜索的fs下，它们会大量的出现在你眼前，要高效的排除干扰并不容易。导致最后我想控制在3层目录几乎不可能，实际依然要cd很多层的目录才能完全消除歧义。所以我才说这里应该需要AI来做更智能的判断，基于机械规则始终是不行的。

【 在 tgfbeta 的大作中提到: 】
: 既然是搜索，如果结果不是unique的，产生了ambiguity怎么办？
--
FROM 180.111.50.*