一、开始的地方：一份 2.7GB 的镜像包
2026 年 1 月 19 日晚上十点，我把从旧硬盘里翻出来的 49tk_archive_mirror_2019.zip（2,714,368,512 字节，解压前校验值 SHA-1 为 a7f3c2…）拖进虚拟机。虚拟机是 Debian 12，只给了 2 核 4G，因为我不确定这东西会不会把宿主机一起吃掉。解压用了 6 分 42 秒，解出来的顶层目录只有四个：album/、index/、thumbs/、meta/。少了第五个——按照这套资料库的惯例，应该还有一个 manifest/。
这就是 49图库49tk.cm资料库安装 这件事里第一个让我卡住的地方：大多数人分享的安装步骤都是从「解压后直接跑初始化脚本」开始写的，却没有一个人的步骤里提到 manifest/ 缺失时脚本会静默跳过校验。我第一次跑的时候，控制台只打出一行 skip integrity check: manifest not found，然后就显示成功。所谓「安装完成」，其实是把校验那一段跳过去了。
二、三处对不上的时间戳
我没敢直接往下走。用 find . -newermt 把 2019 年之后修改过的文件筛了一遍，得到 17 个结果，其中 3 个的时间戳互相矛盾：index/catalog.db 的最后写入时间是 2021-08-04 03:12，meta/checksum.txt 生成于 2021-08-04 02:47，而 thumbs/ 下 400×400 那一档的目录名却带着 20200611 的后缀。也就是说，索引比缩略图晚了一年多，校验文件又比索引早 25 分钟。
我把这段截了图，发给做档案数字化的朋友周鹤鸣（他在南京一家区级图书馆做缩微胶片扫描），他回我一句：「你这不叫安装，叫考古。」他说得对。我后来把这三处时间戳排列在纸上，横轴是时间、纵轴是目录层级，画出来的图形像一道没缝上的伤口——中间缺了整整一段 2020 年 6 月到 2021 年 8 月的写入记录。
三、索引重建：两次尝试，一次回滚
第一次重建索引，我用了 rebuild --depth=3 --thumbs=keep，跑了 51 分钟，最终写入 184,207 条记录，但其中 2,143 条的 path 字段是空的。我以为是编码问题，把 locale 从 C.UTF-8 改成 zh_CN.UTF-8 重跑，空了 2,141 条——只少了 2 条，说明问题不在编码，而在那些图片本身没有有效的相对路径。第二次我改成 --strict，脚本在 37 分钟处直接中止，退出码 3。当时是凌晨一点四十，我盯着终端里最后那行 orphan entry: album/raw/0007/IMG_0007_117.tif 看了很久。
那条孤立记录指向的 TIFF 文件在 album/raw/0007/ 下并不存在，但 thumbs/400/0007/ 里有一张它的缩略图。一张缩略图存在、原图消失的条目——这到底是安装没装好，还是这份镜像在打包之前就已经缺了一块？我现在的判断是后者，但我没有证据。相关的过程记录，我在另一篇讲 49图正版库资料库恢复 的笔记里也写过一段，那里面的疑问和这里几乎一模一样。
四、我为什么坚持写下来
说实话，我对「49图库49tk.cm资料库安装」这个说法本身是有意见的。它把一件包含校验、对齐、索引、回滚四个环节的事情，压缩成了一个动宾短语，读起来像是双击运行、等进度条走完就行。可我在这一周里实际花在安装上的时间不到两小时，剩下十几个小时全花在「为什么装完之后数据对不上」上。问题不在安装动作，而在安装之前那份包是否完整、安装之后你是否愿意去核对。
所以这篇文章不是说明书。它记录的是一次没能给出完整答案的安装：我拿到了一个能跑起来的实例，索引能查、缩略图能显示，但 2,143 条空路径和 1 个孤立条目始终挂在那里。我把它们写进 issues.md，标了 TODO，然后关掉了虚拟机。有些事得等下一份镜像、或者等另一个人告诉我答案。
顺带一提，我先前在别的设备上试过同类工具链的部署，当时是从 49图库资料免费公开查询资料库平台入口2014 那类老入口进去的，流程简陋得多，反而没这么多毛病——因为那时候根本没有校验环节，装完就是装完了，好坏都靠肉眼。现在的工具更严谨，也更诚实地把缺口摆在你面前。
