Multi-Dimension File Management System

 18th February 2020 at 11:52am

多维度的文件管理系统

这个文件管理系统的目的是：更方便地组织文件、检索文件。

背景

我遇到几个使用场景，给了我一些启发。

照片管理

旅游拍了很多照片，需要归类整理。但是文件系统是树状结构，只能把文件夹当作分类来组织照片。这会导致照片没法被更好地组织起来。比如大多数人会以 “日期-事件” 来命名文件夹（比如 201607-西北旅游），但是如果你想整理出不同的旅行中的所有 “亲密合照”，那你需要去多个文件夹里面搜索并且拷贝一份副本。这样非常不灵活。

另外有一个需求是，希望能灵活检索一些文件的元信息。比如照片文件中的 EXIF 信息，或者用户为某些文件自己添加的元信息（比如作者、描述等）。对于照片的例子，如果能读取 EXIF 中的位置信息并进行位置相关的检索就更好了，再如果能结合 Google 的图片 App 进行人脸识别 + 自动分类就更赞了。

全文检索多 PDF, ePub 文件

在看李笑来的《新生》时，他提到了全文检索 ePub / PDF 的需求。我也觉得随着我看的书越来越多，知识体系越来越健全时，我会有更多的电子资料（比如 PDF 书、网页保存的 PDF 等）需要有全文检索的能力。目前几大平台应该有不错的实现了：

  • Windows 上没有去找相应的软件（但是应该有）
  • Arch Linux 上，Plasma 的搜索（Alt-F1 / Alt-F2）有全文搜索功能，但是无预览，只能知道特定的词组出现在哪些 PDF 中
  • OSX 上，Spotlight 可以实现，但是没有具体使用过

但是这个功能是如此重要，如果它整合进这个文件管理系统中，会是个非常不错的特性。

为 Tiddlywiki 提供富媒体文件服务器

Tiddlywiki 的单页应用设计，导致嵌入富媒体文件时：

  1. 如果想不依赖外部链接，需要使用 Data URI 直接嵌入到 HTML 中，导致 HTML 庞大且浏览器性能可能降低
  2. 如果想使用外部链接：
    1. 需要维护外部链接的可用性，比如你可能需要把网络上的播客文件传到你自己的 CDN 上（比如七牛），避免那个外部链接挂掉了
    2. 不方便数据的统一管理，比如不能把全部数据都放在 Dropbox 上

市面上已有的软件体验

Google 搜关键字 "tag based file system", "semantic filesystem"，可以找到几个已有的实现：

  • Tagsistant: 一个特殊的文件系统，在某个空白文件夹初始化后，对这个文件夹的操作，就跟创建 tag、给文件打 tag 等行为关联起来了。感觉不够直观，操作麻烦，功能有限。
  • TMSU: 跟 Tagsistant 一样只能处理文件 tag，但是它的命令行直观得多，而且可以为文件指定 tag 值（像是 attribute）并进行查询。缺点是功能局限于 tagging。
  • TagSpaces: 看起来最不错的一个实现。高级版也支持 PDF / Word 等文件全文检索，也可以给文件打 Tag，用 Tag 查询。缺点是 UI 糟糕难用，性能非常差容易卡（应该是用了 nw.js / Electron 这类技术），同时没法给单个文件写描述。

另外对于照片的场景，我觉得 Google Photos 做得非常好，按人脸聚合以及搜索照片的功能深得我心。但是它有两个缺陷：

  1. 无法按地点搜索
  2. 可以给照片加上描述信息，但是这个描述无法被搜索到，很是鸡肋

所以，如果可能，自己做一个文件管理的软件应该是有作用的。

预期的软件体验

  1. 这个软件可以让用户无需关心文件系统层面的分类（文件夹）。用户只需要把文件丢进我的软件，再进行打 Tag 等操作来管理。
  2. 这个软件应该提供足够灵活的打 Tag + 分类功能，和组合查询功能。比如在 “照片” 分类中，查找拍摄于 2016 年的照片。
  3. 这个软件应试针对某些具体使用场景做优化，比如知识管理、照片管理。

可能的功能细节

  • Tag / Attribute + Category
    • 用户可以为每个文件设置 Tag / Attribute / Category，区别是 Category 只能有一个，并且在整个系统中呈树状结构
    • 提供给用户复合查询的能力，复合查询中需要有操作符提供（e.g. year == 2016）
    • 每个文件都可以写上单独的描述（可以作为一个 description 属性），用于检索
    • 为常用的文件名后缀 / 文件类型，提供预设的 Tag Set，方便用户选择并进行标注。比如对于视频文件，可以给出 Movie Name, Movie Director 之类的 Attributes
    • Tag 是一个没有值的 Attribute，它们在底层数据结构上可以是一致的
    • 可以利用文件本身的 Meta 信息时（比如图片的 EXIF，MP3 的 ID3），尽量使用它用来存储和读取；不可以利用时，单独存储在另外的地方（这里的设计需要考虑，有些时候用户考虑隐私和文件分享，不愿意把 Meta 信息放在文件中）
  • 知识管理
    • 提供常用的富文本格式 / Plain Text 全文检索
    • 最好提供上下文语句，或者渲染出来的预览
    • 如果可以做成 Desktop App，注册一个 Schema URL，供 Tiddlywiki 呼起用来展示 PDF（不是很重要，流程难打通）
  • 照片管理
    • 提供缩略图预览的能力
    • 可能的话，提供按位置信息搜索的能力。可以读取 EXIF 中的位置信息或者自定义的 Tag。比如搜索 “时间：2016 年 + 地点：敦煌 的照片”
  • GTD / 分析文件大小占用，这些功能不重要，不要去实现
  • Tag / Attribute for search and filter. Category for navigation
  • 如果可以，尽量不要用数据库（或者只用 file based sqlite3），不在文件名上存储信息，用单独的文件夹存储。这样可以方便用各类网盘服务同步数据
  • GUI 重要，CLI 可能不重要；最好用 Web-based GUI 技术，但是需要同时考虑性能