崩溃安全的单文件替换

直接覆盖原文件会让旧数据在新数据完整之前消失。替换协议先准备一份独立的新对象，把完整性建立好，再用一次名称发布决定读者看到哪一份。它把大文件写入和小的命名决策分离。

两个同步点保护不同东西。第一个确保新名字一旦指向新对象，就能恢复其完整内容；第二个确保系统已经承诺保留的名字不会在重启后退回旧对象。

四个阶段与恢复答案 ​

初始state→inode45，内容OLD已稳定。独占创建/d/.state.tmp→inode46，按完整写循环写入NEW并设置所需元数据。接着：

1. 对inode46的fd成功fsync，确认新内容可恢复
2. rename临时名到state，原子替换旧名称
3. 对目录d的fd成功fsync，确认名称变化可恢复
4. 才向上层报告持久成功

第三行允许结果未知，但不允许state缺失或指向半写NEW；这条更强结论依赖前述文件系统rename恢复原子性。没有该假设，就不能从一张API调用表推导出同样的允许结果集合。

已经打开旧state的fd仍引用inode45，可能继续读取OLD；rename之后新open取得inode46。协议保证路径发布，不强迫所有历史打开者瞬间改看NEW。

省略同步或拆开重命名会怎样 ​

若跳过临时文件的fsync，目录事务先稳定，恢复可见state→46但内容为空或部分NEW，破坏完整性。若跳过最后目录fsync就报告持久成功，随后崩溃可能恢复OLD，破坏成功后的承诺。

若先unlink旧state，再rename临时文件，两个调用间有真实的名称空窗，且崩溃可能永久失去state。若临时文件在另一文件系统，rename可能失败为跨设备错误；把它改成复制加删除已经是另一协议，不能声称等价。

证明以名称发布为分界：发布前旧对象从未被覆盖，恢复仍可读OLD；发布后新对象的文件同步已经成功，故其内容是完整NEW。恢复原子性排除名称的中间状态，最后目录同步排除成功后回退。这是由对象完整性、名称原子性和同步顺序共同构成的证明，任何一项缺失都有上面的反例。

rename返回成功而目录fsync报错时，应用不应谎报持久成功，也不应断言替换没有发生。当前名称可能已经是NEW，重启结果却尚未获得相同承诺；盲目“回滚”为OLD还会覆盖别人可能观察或随后写出的结果。应将不确定状态交给有版本号或校验的恢复逻辑。

两个文件各执行本协议，仍可能恢复为A新、B旧。若二者有跨文件不变量，可把二者写入带版本号的新目录/对象集合，再原子发布一个清单或根入口；这需要清单引用全部内容先稳定，以及旧版本回收规则。单文件替换不是任意多资源事务。