Restore only the six replication-specific metadata fields after trust validation, so streaming uploads retain their actual content encoding and Snowball entries do not inherit ordinary metadata from the outer archive. Include helper, authenticated PUT/COPY/multipart and Snowball regressions, plus the R7 investigation, actual Opus 5 consensus and local verification. The production change is based on PR #187 by Mikhail Khadarenka. Co-authored-by: Mikhail Khadarenka <chodorenko@gmail.com> Signed-off-by: Feng Ruohang <rh@vonng.com>
3.5 KiB
R7 存量错误元数据处理提案(待单独批准)
本次代码修复只阻止可信复制再次从传输头写入 aws-chunked。升级不会扫描或改写旧对象;普通 COPY 继续保留来源对象的既有元数据。本文件是后续操作的设计,不是已执行的迁移。
1. 只读清单
按桶、键和精确 version ID 记录候选;包含非当前版本,不能只检查最新版本。条件是 Content-Encoding 的逗号分隔 token 中包含 aws-chunked。若大小写、空格或重复值异常,单列人工核验,不能凭字符串子串匹配改写。
清单至少保存:来源及目标站点、bucket/key/version ID、完整原始 Content-Encoding、拟保留编码、ETag、对象大小、可用内容校验值、修改时间、完整普通及用户元数据、标签、Object Lock/保留期/法律保留、SSE 模式及必要密钥的可用性、复制状态。清单不保存 SSE-C 密钥或凭据。读取响应时禁用客户端自动 gzip 解码,以便核对原始字节。
仅凭错误响应头不能判断字节是什么。比对可信来源版本或独立的原始内容校验值;有 gzip 的对象确认其字节确为 gzip 并保持原字节,不重新压缩。来源也受污染、来源版本不存在或校验依据不足时,标记为需调查,不自动修复。
2. 制作具体变更清单
优先确认并处理权威来源的精确版本,再协调副本。若来源仍保存错误编码,复制比较器会把规范化后的目标判断为不一致;在后续 heal/resync/比较时可能反复选择元数据复制。多向复制须核对整组来源和副本,记录持续不一致及重复元数据复制。这个风险不等于已证明存在不间断重试热循环。
原则上只删除被证实属于传输层的 aws-chunked token:仅有该 token 时移除 Content-Encoding,有其他编码时保留顺序和值。每条候选给出前后值和可回滚的元数据快照,其余内容、元数据和对象标识的保持条件逐项列出。
普通 S3 自 COPY 可能创建新版本、更新修改时间和复制排序;它不能被当作通用的原版本元数据修复 API。先在本地同配置克隆中验证可用的受支持管理/元数据操作,再选择方案。如果必须创建替代版本,要在清单中明确 version ID、当前版本关系和调用方影响。如果没有受支持的安全路径,停止该项,不编辑 xl.meta 或内部盘文件。
3. 审批与小批执行条件
批准的是具体清单和已经验证过的写入方式。执行前再次核对 version ID、ETag、大小、原元数据和时间等并发保护;ETag 单独不足以检测元数据更新。明确写入协调或维护窗口,发生冲突则跳过。Object Lock、SSE-C、生命周期和双向复制等条件分别验证;不得为了修元数据绕过保留限制。
先在可回滚的小批次验证:精确版本 HEAD 的 Content-Encoding 正确、GET 原始字节/校验值一致、对象锁和其他元数据没有被丢弃、目标站点版本与复制状态最终一致。留下逐项结果、冲突、跳过和失败日志,再决定扩大批次。
4. 回滚边界
保留不可变清单和完整元数据备份;为选用的具体操作验证回滚步骤。若写入创建了新版本,回滚必须考虑 version ID 和当前版本关系,不能用“再 COPY 一次”代替证明。代码回滚会重新开放新污染入口,并不会自动还原任何已修过的元数据。
本任务未对现网执行清单扫描、对象写入、版本调整、部署或存量修复。