Pack：一种用于压缩文件的新容器格式

Pack 概览

• 基于 SQLite3 作为结构、Zstandard 作为压缩的新归档/容器格式。
• 目标是对大量文件（尤其是大量小文件）进行极快处理、支持内容随机访问、提供简单的 CLI，并为未来的操作系统集成做准备。
• 使用 FreePascal/Lazarus 以 Pascal 编写；设计上希望代码读起来像伪代码。

性能与基准测试

• 作者声称相较 tar/zip/7‑Zip 有很大提升，尤其是在包含数万小文件的目录树上；举例称 Linux 源码树可在约 1–1.3 秒内打包，且输出更小。
• 其他人复现实验后看到的提升更小但确实存在（当两者都调优良好时，通常相对 tar+zstd 为约 1.3–1.7×），并不像某些图表暗示的那样是“数量级”差距。
• 有人怀疑其中一部分速度提升来自多线程和 Windows/NTFS 的异常，而非某种根本性的新思路。
• Zstandard 的速度/压缩率权衡受到广泛称赞，被认为是 Pack 性能的重要因素。

SQLite3 与 Zstandard 的使用

• 支持者认为：SQLite 文件格式稳定、文档完善、使用广泛，并承诺兼容到 2050 年；如果使用 SQLite 绑定，替代实现也会更容易。
• 批评者认为：这会把规范绑定到单一的 C 实现及其怪癖上；由于 SQLite 需要完整数据库，不适合流式/管道场景；损坏文件恢复和远程/NFS 行为可能很棘手；SQLite 也不太适合作为通用交换格式。
• Pack 会替换 SQLite 的魔数，因此归档无法直接用通用 SQLite 工具打开；内部有自定义表（Content、Item、ItemContent），但目前还没有明确的磁盘格式规范。
• 作者提供了一个 CLI 模式，可将 Pack 文件转换为“真正的” SQLite3 以便调试，再转换回来，并使用带有内部版本机制的自定义 VFS。

格式特性与设计选择

• 随机访问和选择性提取（--include）是核心目标；作者称能在数十毫秒内从大型归档中提取单个文件。
• 文件会被分块为约 8–32MB 的“contents”；不可压缩区域（例如媒体文件的某些部分）可以不压缩存储，而其他部分则压缩。
• 不存储文件系统元数据（所有者、模式、时间戳）；这是有意为之，目的是避免跨 OS 不匹配和泄露本地细节，不过也有人希望可选保存元数据。
• 目前不支持流式/管道（tar | ssh tar 之类）；作者表示这在计划中，但暂时不是优先项。
• 压缩调优被刻意简化（普通与 --press=hard 两档），有些用户喜欢这样，另一些则希望对 Zstd 级别有更细粒度的控制。

语言选择（Pascal）

• 许多人对一个新的系统工具使用 Pascal 感到惊讶；反应从欣喜到“为什么不是 Rust/Go/C++？”不等。
• 作者认为 Pascal 稳定、可读、生命周期长；一些讨论提到 Wirth 系语言强调约束与正确性，而不是“C 式叙事”。

与现有格式的比较

• Squashfs 和 dwarfs 被提为强大的只读、支持随机访问的压缩文件系统；Pack 的不同在于它原则上可更新，而且作为归档工具更“面向用户”。
• sqlar（基于 SQLite 的归档）被视为前作；作者展示其测试中 Pack 在速度和体积上都明显胜出。
• tar 被批评为面向磁带、难以并行、缺乏随机访问；也有人指出它在流式和管道方面的优势。
• zip 因无处不在和简单而受到称赞，但在元数据怪癖和边缘情况文档不足方面受到批评。
• 还提到了 ZPAQ/PAQ 以及高压缩率压缩器；Pack 明确追求的是速度 + 足够好的压缩，而不是极限压缩率。

采用、可移植性与信任

• 目前只有 Windows 和 Linux 的二进制文件；尚无 macOS 构建，而且从源码编译需要遵循项目特定脚本。
• 有人报告早期二进制存在运行时错误或大小异常；也有人担心 SQLite 编译时未启用线程安全，但代码看起来是多线程的。
• 一些评论者对匿名维护和缺乏正式规范感到不安；作者回应说，信任应来自代码、许可证和可复现构建，而不是身份。
• 总体共识：这是个有趣的想法，性能特征也很有前景，但在被视为严肃的“通用” tar/zip 替代品之前，还需要更清晰的规范、更广的平台支持、可靠的线程保证以及更好的文档。