意外数据丢失的总结

这次事故并不涉及硬件故障, 偶也不太可能找到重现的机会.
比较微妙的是只丢了一个目录. 但是失误的是就算做了全盘复制镜像, 考虑到 SSD 的 TRIM 特性, 文件应该确实已经不在了, 这个因为有镜像所以如果有空可以再做一次分析, 但很可能是不会再动了.
以前偶用过扩展名文件分类法. 偶应该重新引入这个东西.
如果重新设计这个方案的话, 应该是每周(每日也可以, 但可能需要查看一下 atime 以避免伤及正在使用的文件?)将指定的目录的文件按文件大类型分类, 移入 YEARMONTH_category 目录.
zip/rar archive 之类可能需要特别处理, 这里的重点是最好能避免原地解压, 不能避免也要设法留底知道解包后的文件是哪里来的.
---
如果一个目录或者分区已经放了很多东西需要整理, 这里顺便介绍一下偶以前写的一个工具 filecounter
https://gist.github.com/fcicq/5c9bfcd67cca8e61d025
除了 10MB 以上的文件会单独提示以外, 提示都是针对目录的, Large* 系列计数超过阈值发出提示后对上级目录等同于清零.
含有超过 15 个子目录的目录会提示 LargeSubDirs.
累计超过 150 个文件的目录会提示 LargeFileNum.
文件总大小超过 128MB 的目录提示 LargeDirSize.
单目录文件扩展名种类数超过 7 种提示 ManySufTypes.
单目录 32KB 以内的小文件超过 20 个提示 ManySmallFil.
只有检测功能, 遇到这些情况是否需要纠正各人肯定会有不同的意见, 这里就不强求了.
---
之前说过天朝的各种云存储的 API 和 S3 就是很接近, 但那几个差异的细节就是非常恶心, 结果是给 S3 写的第三方客户端都用不了.
正在检讨要不要动手折腾一个兼容层, 虽然如果只是偶自己用的话成本就太高了.