摘要

  • PDPArchive 第 03 版首次明确以 POSIX pax 为打包格式，可对整包使用 gzip 或 Zstandard，并允许一个逻辑归档拆成多卷。
  • 草案要求导入方在写入文件前拒绝绝对路径、.. 越级路径和特殊条目类型；文件应采用导入方自己的默认权限，不得套用归档中的属主、模式位、扩展属性或 ACL。

箱子里有数据，没有新服务器的命令权

这个工作组想让个人邮件、通讯录、日历等数据以通用形式迁移。上一版主要描述箱内的文件和元数据；10 月 28 日修订把箱子也定义了：使用 POSIX pax，一种能携带扩展路径与大小信息的 tar 家族格式。导出方只能放普通文件或目录，不能塞进符号链接、硬链接或设备文件。IETF 状态页仍将它列为工作组草案，而非已经生效的 RFC 或某家服务的部署报告。

文件名一旦进入导入流程，就变成新服务器“写到哪里”的指令。草案要求 UTF-8、相对路径、不能含 . 或 .. 路径段；同一卷内的条目名必须唯一。导入方须在落盘前核验，拒绝绝对路径、越级路径和普通文件/目录之外的条目。更硬的一刀落在权限上：归档里的模式位、属主、扩展属性与访问控制列表都不能直接应用，新文件由接收方自己的默认配置创建。旧服务可以打包个人资料，不能替新服务指定文件主人。

还有一类不起眼的碰撞。Inbox 与 INBOX 在归档中可以是不同名字，在不区分大小写的磁盘上却可能占同一个位置。Unicode 不同规范化形式也会造成类似问题。草案要求导出方尽力生成跨这些规则仍可区分的名称，并建议导入方拒绝重复命名条目，不要默默覆盖其中一份。可携带性不能靠丢文件换取。

大文件夹可以拆到不同归档卷里，但不能拆成两份身份。每卷都须能独立读取，自己的 archive.json 除 part 与 final 外保持一致。跨卷的同一文件夹沿用 UID，相关元数据一致，删除清单 removed 在每份副本里重复；导入方必须把它们合并成一个文件夹。归属关系靠稳定 UID，而不是纸箱上看起来相似的名称。

整包可不压缩，也可用 gzip 或 Zstandard。导入方必须接收未压缩和 gzip，应该接收 Zstandard。草案提醒接收方考虑解压后的总量、条目数和单条目大小，但没有规定统一数字上限。它还指出：上传包里的角色与共享权限可能被篡改，接收方须判断这些声明是否值得信任。能打开箱子与能相信箱内权限，是两种不同的判断。

下一个可检验的事实是工作组最终如何定稿，以及不同导入程序能否在分卷、碰撞和权限处理上得到相同结果。现在这仍是草案，未给出某次真实迁移的成败记录。

来源：第 03 版原文；第 02 版；IETF 状态；RFC 1952；RFC 8878。