Object Lock 复制排序

2026-09-16 发布边界：f4c1286c9 已随 Server 20260903 发布。后续仅时间戳删除、SSE-C 重传和跨池修复见 #129、#134、#178，它们在 main 中，但不在该发布中。公告台账 记录原始排序缺陷。

重建元数据前保留旧状态

副本 COPY 曾在比较保留期和 legal hold 时间戳之前，就用入站请求重建元数据。旧时间戳因此丢失，旧请求看起来也能成为权威更新；legal hold 时间戳还写错到保留期时间戳键。第一批修复在重建目标 map 前捕获已存状态，并让各字段版本保存在各自键中。

保留期和 legal hold 是独立寄存器。较新的保留期不会让较旧的 hold 变得权威，对象修改时间也不能替代任一字段版本。只有入站字段时间戳更新时才应用，旧值或等时间戳更新保留已存状态。

删除同样是有序值

移除保留期或 hold 后可能没有活值，但仍携带源时间戳。丢掉时间戳会让延迟旧值回来。后续修复在接收、比较和重发时识别仅时间戳的删除；没有排序证据的缺失字段，与已记录删除是不同状态。

接收端必须在普通元数据 COPY 和完整 SSE-C 副本重传中保留这些差异。对象体重写不能成为删除目标更新 hold 或恢复旧保留期的理由。

跨池权威状态

同一版本在多个池有副本时，单个 set 不能独自决定最新字段状态。多池协调层 在共享对象锁下收集同版本副本，分别按时间戳合并保留期和 hold。未知池状态不是空值；该修复关闭了原先以 #133 留下的源码边界。

授权与限制

排序不会授予修改 Object Lock 的权限，复制信任检查和相关 S3/admin 权限仍然适用。这不是绕过 governance 或 compliance 保留的新用户 API，也不建立不同步源时钟间的因果顺序，更不提供部分存储失败后的分布式回滚。

历史旧更新可能已经改变存储状态。升级只能阻止修复路径再次接受同类错误，不能重建丢失的保留历史。宣布恢复前，应在各站点按权威记录核对精确版本的保留期和 legal hold。

证据

参考 Object Lock 合并实现、erasure-object.go 的副本写入路径及关联 PR。测试覆盖字段的新旧更新、空值删除、独立字段时间戳、SSE-C 重传和多池；这些源码测试不证明所有历史副本都已收敛。

结合副本审计手册、SSE-C 完整性记录和发布矩阵使用。依赖组合排序契约前应升级所有参与节点。