已知问题
当前机制边界、可能造成的影响及避免数据丢失的方法。
Last updated on
以下是当前源码中已确认的机制限制，不是某次安装偶发的故障。KI-01 和 KI-03 在 v1.13.1 之后的开发版代码中得到核实，是否影响更早的发行版尚未确认。所列操作只能降低风险，无法消除根本原因。提交问题前请先确认症状是否相符，避免重复报告；若现象不同，请附上日志及涉及的文件。
当前限制
| 编号 | 适用版本 | 触发条件 | 可能的表现 | 避免措施 |
|---|---|---|---|---|
| KI-01 | 当前开发版（v1.13.1 之后） | 本地保留的符号链接被运行目录中的普通文件取代 | 同路径两个副本中的一个可能在部署时被丢弃或覆盖 | 先备份运行目录副本，成功部署后再创建快照 |
| KI-02 | 当前开发版；最早受影响发行版未核实 | 整合包源与工作副本内容变化，但修改时间无法区分 | 工作区可能不显示已变更文件 | 同步或发布前自行比对内容 |
| KI-03 | 当前开发版（v1.13.1 之后） | 快照恢复或部署写入两份投影清单的中途被打断 | 下次部署可能依据不同状态的清单继续处理 | 备份运行目录、检查文件后重新完成被中断的操作 |
KI-01：本地保留与运行目录出现双副本
本地保留（persist/）中的单文件通过符号链接放入运行目录（build/）。有些程序先通过链接写入，再删除链接并在同路径创建普通文件，此时两侧内容可能不同。部署只依据本地保留文件自上次投影以来的修改时间来选择副本，无法判断哪次写入真正发生得更晚。若本地保留的时间戳已变化，即使 build/ 副本包含更晚的修改，部署也会丢弃它；否则会将 build/ 副本回迁到本地保留。
部署前若发现两侧同时存在不同文件，请检查并备份 build/ 中的普通副本。创建快照前先成功部署一次：快照保存本地保留，但不保存尚未回迁的运行目录普通副本。重要存档和配置还应另行备份。这是已记录的模型限制，目前不计划在部署或快照机制中修复。目录用途参见目录模型。
KI-02：工作区仅比较修改时间
工作区通过工作副本和整合包源文件的修改时间判断新旧。如果时间戳相同，即使内容不同也会视为未变更。保留时间戳的工具因此可能改写文件，却不使它出现在工作区列表中。工作区还会忽略投影的符号链接。
发布整合包时，如果重要文件的时间戳可能被保留，请使用文件比较工具核对 import/ 与 build/ 的内容。工作区列表为空不等于内容完全一致；当前比较没有内容哈希的后备检查。
KI-03：两份投影清单并非原子写入
部署与快照恢复通过 build/trident.import.json 和 build/trident.persist.json 两份文件记录运行目录中整合包源与本地保留的归属。它们按顺序写入，而不是作为一次事务提交。两次写入之间发生崩溃、取消或磁盘故障，可能使两份清单描述不同的状态。下次部署会依据磁盘上已有的清单继续，无法自动将两份一起回滚。
尽量不要在部署或恢复收尾时取消操作。如果操作已中断，先停止其他写入程序，备份 build/ 中仍有价值的文件，检查实例，再重新完成被中断的恢复或部署。后续操作前核对存档和工作副本的变化。重做操作无法找回已经丢失的文件，重要数据必须另有备份。当前机制没有跨文件事务或自动回滚。