Windows installer cleanup follows NTFS junctions and can empty the new runtime

[Hylouis233]

在 Windows x64 上，有一条可复现的安装器清理路径：旧安装目录内的 NTFS directory junction 会在更新收尾时被递归访问，从而删除新安装的 runtime 文件。

本机更新至 0.2.1-rc.5 后，Host 启动时读取 resources/runtime/office-skills/office/SKILL.md 报 ENOENT，runtime 根目录仍在但内容为空。缓存安装包的 SHA-512 与更新元数据匹配，解包后包含完整的 6,150 个运行文件。随后使用当前上游目录事务代码，在隔离目录中复现了下面的删除路径。

证据来自安装文件检查和隔离复现，没有那次真实升级的完整事务跟踪。

复现路径

1. 旧安装内存在 resources/app/runtime 目录联接，绝对目标是最终安装位置的 resources/runtime。
2. 更新时旧安装被整体改名为 Application.old-{GUID}，新安装被提升到 Application。联接的绝对目标仍是 Application/resources/runtime。
3. dshFinishDirectories 对旧安装执行递归 RMDir /r。NSIS 会跟随该联接，删除新 runtime 的内容，留下空目录。

Application.old-{GUID}/resources/app/runtime
    -> Application/resources/runtime

原生隔离复现中，清理程序退出 0，旧安装目录消失，同时新 runtime 的 sentinel 文件也消失；runtime 根目录仍存在。取消安装时，待安装目录内指向保留资源的联接也有相同风险。

补丁

官方 CONTRIBUTING 暂不接收外部 PR，GitHub 也拒绝了创建请求，因此按贡献指南在 Discussions 提交报告，并保留以下可审阅补丁：

• 草稿 PR：fix(desktop): preserve junction targets during Windows cleanup Hylouis233/deepseek-harness#1
• Commit：Hylouis233@a8e07ce

补丁让更新收尾、回滚和卸载复用现有原生删除实现，只解除重解析点，不枚举其目标。新增入口将清理限定为选定安装目录及 GUID 命名的 .new- / .old- 同级目录，并固定父目录句柄。双语打包文档及回归 fixture 一并更新。

验证

• 修改前，新增 upgrade-junction 场景在普通首次安装和升级通过后失败：新 runtime 的 sentinel 已被删除。
• 修改后，真实 Windows 文件系统、x86 原生 DLL 和静默 NSIS 目录事务的 11 个场景全部通过，包含 upgrade-junction 和 cancelled-junction。
• 卸载模板的 7 个测试、原生清理回归、完整构建 10/10 项、lint 和 pre-push typecheck 5/5 项通过。
• 文档检查的 42 项通过；首次 doc-typecheck 因隔离 PATH 缺少 npm 失败，补齐环境后重跑通过，104 个代码块编译成功。
• hygiene 为 22 项通过、1 项失败。唯一失败为原有 vendor rescope 标记检查；在未修改的同一 upstream/master worktree 中复现相同失败。补丁没有更改 vendor 或削弱检查。

签名产品安装包的真实跨版本升级仍需发布者验收。

实现、测试设计和报告由 AI 代理在作者授权下完成，详细 AI 声明和命令证据见草稿 PR。

[FenrirCait]

A small data point for this thread (from a machine that hit the same "runtime empty → Host fatal" on 0.2.1-rc.5 → 0.2.2-rc.1, see #11824).

Enumerating the whole install tree here (D:\Software\DeepSeek Harness) returns exactly one reparse point, and it is one the installer/app creates itself:

resources\app\runtime  ->  resources\runtime
  junction created : 2026-11-04T14:36:21Z
  target birth     : 2026-11-04T14:31:56Z   (resources\runtime)

Both timestamps are from the rc.5 reinstall after the failure (14:31Z ~ update/reinstall window, 14:36Z when resources\app was created), so I can't prove the link existed at the moment of the failed update (14:13Z). Still, two things seem worth checking:

1. If the installer always lays down resources\app\runtime -> resources\runtime, then "zero reparse points" in [Bug] Desktop in-app update leaves resources\runtime empty → Host fatal on next launch (0.2.1-rc.5, no junctions involved) #11824 only means no user-created junctions — the cleanup path can still traverse this one when it deletes/replaces resources\app*.
2. If cleanup deletes resources\app first and re-extracts afterwards, the junction disappears with it and resources\runtime survives; if it deletes through the junction, resources\runtime is emptied while app.asar is already the new version — which is exactly the observed mixed state.

So this may be less "junction following breaks the update" and more "the update's own junction makes deletion ordering unsafe". Worth a look at the order in which resources\app, resources\runtime and app.asar are removed/restored in the --updated path.