- 主题:发现一个影响办公效率的问题
常用目录可以“钉”到资源管理器的常用链接里面，就像我的文档、下载这些一样
【 在 gnwd 的大作中提到: 】
: 经常打开不同目录的文件，在目录中跳转来跳转去，耽误不少时间。有时候为了目录管理有条理，目录层次还不算浅。
: 但其实这几个月常打开的可能就这几份或者十几份文档。
: 当然可以建一个目录，往里面扔符号连接。不知道有没有别的更好的方法
--
FROM 113.57.182.*
好厉害
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 大概05年前后，我觉得所谓的目录管理有条理是个伪命题。因为一个文件你可以按照不同的维度去切割分类，你分的越细越有条理，就越容易遇到另一种非常难检索的维度。
: 于是我基于fuse做了一个虚拟文件系统，把目录的层级作为搜索关键字，比如cd a/b/c，进入的目录其实就是用a b c作为关键字去搜索匹配后的所有文件。这里因为是关键字，所以顺序就不重要了，cd c/b/a和a/b/c的结果是一样的。也即你可以随心所欲的按照你想要的tag cloud方
: 总之，要完善细化还需要不少后续工作。但我觉得这个基本理路是可以针对这类需求的。
: ...................
--
FROM 163.177.68.*
突然觉得这个fuse是不是没法ls啊
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 标 题: Re: 发现一个影响办公效率的问题
: 发信站: 水木社区 (Thu Feb 25 10:39:45 2021), 站内
:
: 你这另一半也好解决。。别用命令行就行了 :-)
:
: 【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: : 一半是这样，另一半就是用文件系统作为入口。
: : 其实我最初的目标是能快速进入我想要的目录。
: : 比如一个文件我放在a/b/c/d/e/f/g/foo.txt
: : ...................
:
: --
: 灭绝人性啊
:
:
: ※ 来源:·水木社区 newsmth.net·[FROM: 112.47.122.*]
--
FROM 163.177.68.*
既然是搜索，如果结果不是unique的，产生了ambiguity怎么办？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 大概05年前后，我觉得所谓的目录管理有条理是个伪命题。因为一个文件你可以按照不同的维度去切割分类，你分的越细越有条理，就越容易遇到另一种非常难检索的维度。
: 于是我基于fuse做了一个虚拟文件系统，把目录的层级作为搜索关键字，比如cd a/b/c，进入的目录其实就是用a b c作为关键字去搜索匹配后的所有文件。这里因为是关键字，所以顺序就不重要了，cd c/b/a和a/b/c的结果是一样的。也即你可以随心所欲的按照你想要的tag cloud方
: 总之，要完善细化还需要不少后续工作。但我觉得这个基本理路是可以针对这类需求的。
: ...................
--
FROM 117.10.133.*
基于 xapian 做后台文本搜索然后生成 shell 中的自动补全呢？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 所以我更多的是想想嘛，自己是懒得去搞了。
: 提个愿望也许有人帮我实现了呢～
--
FROM 73.158.11.*
这就是核心问题了。
首先考虑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.*
自动补全倒是个可行的替代思路，不过自动补全也基本只有shell里用了吧。
【 在 zyxwvutsrqp 的大作中提到: 】
: 基于 xapian 做后台文本搜索然后生成 shell 中的自动补全呢？
:
--
FROM 180.111.50.*
这个问题在大方向上很像 cloud object store. 具体在文件系统上是怎么存的并不重要, 重要的是让人能够以 /a/b/c/foo.txt 的方式很快生成 hash 指向到文件。/a/b/c/foo.txt 这种的只用来助记, 不应要求 unique, 最终有唯一性的是 hash
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 自动补全倒是个可行的替代思路，不过自动补全也基本只有shell里用了吧。
--
FROM 73.158.11.*
对，简单的说我们标记文件有两种思路。
一种是文件系统目录，是包含关系。
另一种是tag cloud，是并列关系。
我们之所以觉得文件系统存东西不够用，是因为某些需要并列关系的场合用目录来存放很扯蛋。
但完全放弃包含关系，完全用tag cloud来检索文件，也非常容易带来混乱。
重点就是如何在这两者之间取得平衡。
而且这种平衡还是比较主观的，所以我才觉得用AI来搞是一种比较好的出路。
【 在 zyxwvutsrqp 的大作中提到: 】
: 这个问题在大方向上很像 cloud object store. 具体在文件系统上是怎么存的并不重要, 重要的是让人能够以 /a/b/c/foo.txt 的方式很快生成 hash 指向到文件。/a/b/c/foo.txt 这种的只用来助记, 不应要求 unique, 最终有唯一性的是 hash
:
--
FROM 180.111.50.*
厉害，以后cd命令要内置强化学习了
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 这就是核心问题了。
: 首先考虑duplication，这个感觉是可以合并的。但编辑文件的时候就又有问题了，因为一份文件在几个目录里面复制几遍完全合理。有的场合是只更新其中一个，有的场合又希望全盘所有副本同步更新，具体要哪个是我说了算的。
: 其次就是你说的ambiguity问题。结合duplication问题，我不得不对模型进行了一些简化。在你不断cd（也即不断提供更多的搜索关键字）的过程中，返回的结果是从全盘搜索结果的aggregation到一个精确的sub folder的逐步过渡过程。最终在你提供了足够的信息，完全消除歧义之
: ...................
--
FROM 117.10.133.*