[desktop] 升级后 D:\dsh\resources\runtime 被装成空目录 → 宿主 fatal（0.2.1-rc.5 / rc.3 共 3 次）

[ZiYuan258]

Summary

桌面版应用内升级后，安装目录 D:\dsh\resources\runtime 被装成空目录（正常应为 6,148 个文件 / 257.3 MB），下次启动宿主直接 fatal，界面只显示 "DeepSeek Harness is unavailable"，用户无法进入应用、也看不到日志。

到目前共发生 3 次：2026-10-24（0.2.1-rc.3）一次、2026-10-30（0.2.1-rc.5）两次。

关键点：用同一份更新器缓存里的安装包手动原位重装（%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer.exe /S /D=D:\dsh）可以立刻恢复全部 6,148 个文件，应用随即正常启动 —— 所以安装包本身没问题，问题出在"升级路径"（很可能是应用/宿主仍占用安装目录时替换文件失败，而失败被当成了成功）。

Reproduction

1. 应用（含 host 子进程）在运行状态下触发应用内更新，升到 0.2.1-rc.5；
2. 更新流程结束、应用被重启；
3. 启动即 fatal，resources\runtime 为空目录。

rc.3 那次（10-24）同样如此。手动重装之后再次触发更新 应该能复现（我这边的环境已经修好，暂不方便再造一次，如果官方需要我可以配合复现）。

Current behavior

• 弹窗 "DeepSeek Harness is unavailable"，界面进不去。
• %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-30T02-18-27-675Z-host.log、crash-2026-10-30T02-19-02-060Z-host.log：

DesktopHostFatalError: ENOENT: no such file or directory, open 'D:\dsh\resources\runtime\office-skills\office\SKILL.md'
    at ChildProcess.<anonymous> (file:///D:/dsh/resources/app.asar/lib/main.js:3831:49)
host diagnostic:
Error: ENOENT: no such file or directory, open 'D:\dsh\resources\runtime\office-skills\office\SKILL.md'
    at readFileSync (node:fs:483:20)
    at file:///D:/dsh/resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-skill-office/lib/index.js:64:38

• 10-30 那两次失败的升级在 %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\ 里没有留下任何记录（静默失败，连现场都没有）。
• 用户数据（%APPDATA%\@deepseek-ai\dsh-desktop 下的会话/配置）没有丢失，坏的只有程序目录里的 resources\runtime。

Expected behavior

1. 升级要么完整成功，要么明确失败并可回滚 —— 不应留下半损坏的安装目录；
2. runtime 缺失时宿主不应 fatal：至少给出可读错误（"runtime 缺失，请重新运行安装包"）并让应用能起来；
3. 静默安装/更新路径也应写 installer-logs。

Environment

项	值
OS	Windows 10 Home China 25H2，CurrentBuild 26200，UBR 9457
应用	@deepseek-ai/dsh-desktop 0.2.1-rc.5（另一次 0.2.1-rc.3）
Electron / Node	44.7.0 / 24.21.0
安装目录	D:\dsh
正常大小	resources\runtime = 6,148 个文件 / 257.3 MB
更新器缓存	%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater

---

以下是完整证据、时间线与修复建议。

Abstract (EN). Twice reported, thrice observed: after an in-place update, <install>\resources\runtime ends up empty (should be ~6,150 files / 257 MB). On next start the host dies with
DesktopHostFatalError: ENOENT: no such file or directory, open '<install>\resources\runtime\office-skills\office\SKILL.md' and the UI only shows "DeepSeek Harness is unavailable".
Re-running the cached installer (installer.exe /S /D=<install>) restores everything, so the payload is fine — the update path is what fails, likely because the app/host still holds files under the install dir while NSIS replaces them (MoveFileExW error 32 / error 5 in older logs). The 2026-10-30 failure left no installer log at all, i.e. it failed silently and still counted as success. Suggested fixes at the bottom.

---

环境

项	值
OS	Windows 10 Home China 25H2，CurrentBuild 26200，UBR 9457
应用	@deepseek-ai/dsh-desktop 0.2.1-rc.5（另一次是 0.2.1-rc.3）
Electron / Node	44.7.0 / 24.21.0
安装目录	D:\dsh
正常大小	resources\runtime = 6,148 个文件 / 257.3 MB（Get-ChildItem -Recurse -File 口径；`find
更新器缓存	%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater

---

症状

1. 应用内点更新。更新过程没有报错，应用被重启。
2. 启动后弹出 "DeepSeek Harness is unavailable"，界面进不去。
3. D:\dsh\resources\runtime 是空目录（或只有部分内容）。
4. 用更新器缓存里的同一个安装包原位重装一次（%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer.exe /S /D=D:\dsh）→ 立刻恢复 6,148 个文件 / 257.3 MB → 应用正常启动（5 个进程，窗口与 UI 正常，无新崩溃日志）。

用户数据（%APPDATA%\@deepseek-ai\dsh-desktop 下的会话、配置）没有丢，坏掉的只有程序目录里的 resources\runtime。

发生记录

时间（本地）	版本	结果
2026-10-24 14:23	0.2.1-rc.3	fatal，runtime 空
2026-10-30 10:18:27	0.2.1-rc.5	fatal，runtime 空
2026-10-30 10:19:02	0.2.1-rc.5	fatal（再次启动，仍然空）
2026-10-30 10:20	0.2.1-rc.5	手动原位重装后恢复

证据

1. 宿主 fatal 日志（%APPDATA%\@deepseek-ai\dsh-desktop\logs\）

crash-2026-10-30T02-18-27-675Z-host.log 与 crash-2026-10-30T02-19-02-060Z-host.log：

phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.5
platform: win32 x64 / electron: 44.7.0 / node: 24.21.0
DesktopHostFatalError: ENOENT: no such file or directory, open 'D:\dsh\resources\runtime\office-skills\office\SKILL.md'
    at ChildProcess.<anonymous> (file:///D:/dsh/resources/app.asar/lib/main.js:3831:49)
host diagnostic:
Error: ENOENT: no such file or directory, open 'D:\dsh\resources\runtime\office-skills\office\SKILL.md'
    at readFileSync (node:fs:483:20)
    at file:///D:/dsh/resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-skill-office/lib/index.js:64:38

同一错误在 10-24 的 crash-2026-10-24T06-23-29-363Z-host.log（0.2.1-rc.3）中完全相同 —— 不是 rc.5 回归，是长期存在的升级路径问题。

2. resources\runtime 目录本身的时间戳

CreationTime    : 2026/10/30 10:20:04     ← 手动重装那一刻被重新创建
LastWriteTime   : 2026/10/29 22:02:52
内含            : bin\, cli\, office-skills\, primary-runtime\, versions.json
所有文件 mtime  : 2026/10/29 22:02:52（= rc.5 正常安装的时间）

即 10 月 29 日 22:02 是一次正常安装；10 月 30 日 10:13~10:14 的自动更新把目录清掉了，10:20 手动重装才恢复。

3. 安装器自己记录的同类失败（...\updater\installer-logs\directory-failure-*.log）

Operation: MoveFileExW
Windows error: 32 (另一个程序正在使用此文件，进程无法访问。)
Source: D:\dsh
Destination: D:\dsh.old-{3A45FA5A-0211-4AC0-9830-3A3F5EF21421}
Restoration error: 0
Time: 2026-10-17 17:52:33
Windows: 10.0.26200

外加 10 条 backup 尝试（error 5 ×5、error 32 ×5）。

另一份 directory-failure-20261017-175542.log：

Windows error: 5 (拒绝访问。)
Destination: D:\dsh.old-{2BF4B9BC-DB18-481F-8366-7C725110CCF7}
backup error 5 ×10

这类"目录被占用 → 改名/替换失败"的失败模式与本次症状吻合：安装器试图把 D:\dsh 整个改名成 D:\dsh.old-{GUID} 再放新目录，失败后安装目录处于半损坏状态，而 resources\runtime 这种"后解压"的目录就成了空的。

4. 2026-10-30 那次失败没有留下任何安装器日志

installer-logs\ 里只有 10 月 17 日的两个文件，10 月 30 日的两次升级一条都没有。也就是说这次失败在日志里完全静默 —— 只能从宿主崩溃日志反推出来。这一点单独就值得修：静默安装/更新路径必须记录自己的失败。

5. 缓存中的安装包是好的

installer.exe                              289,408,544 B   2026-10-30 10:14:12
pending\deepseek-harness-0.2.1-rc.5-win-x64.exe  289,408,544 B   2026-10-30 10:14:12
pending\update-info.json: {"fileName":"deepseek-harness-0.2.1-rc.5-win-x64.exe",
  "sha512":"gu2dH+aTr678c0P8DGAH/h4B1GaWfQIjpsPrLjl/ukLrQIh6DLVq/MhX4FZvJ8o1GCMocOhix6XbLa6KmtjXXg==",
  "isAdminRightsRequired":false}

同一个包手动跑一次就装好了 → 包没问题，是"什么时候、以什么方式跑它"有问题。

复现路径（推测，与日志时间线一致）

1. 应用在运行（有主进程 + 渲染进程 + host 子进程）。
2. 更新器下载完成，启动 installer.exe /S 原位升级。
3. NSIS 试图替换 D:\dsh 下文件；此时应用/宿主仍持有 resources\app.asar、resources\runtime 里的文件 → MoveFileExW 失败（error 32 / 5）。
4. 安装器没有把这种局部失败当失败（返回成功，或不写日志），更新器继续重启应用。
5. 新版本启动，读 resources\runtime\office-skills\office\SKILL.md → ENOENT → DesktopHostFatalError → UI 只显示 "DeepSeek Harness is unavailable"。

建议的修复

按性价比排序：

1. 升级前真正退出应用并等待句柄释放。 不要只 app.quit() 就立刻跑安装器：要等所有进程（含 Electron helper、host 子进程）消失，并确认 resources\app.asar 不再被占用（可以试着重命名探测）；超时就中止升级并提示"请手动退出 DeepSeek Harness 后重试"，而不是硬着头皮装。
2. 安装后自检 + 失败回滚。 装完检查 resources\runtime\versions.json、bin\、office-skills\office\SKILL.md 是否存在、文件数是否达到阈值（约 6,000）。不达标：把 .old 目录换回去或报错，退出码非 0，让更新器不要把这次更新当成功。
3. 别原地覆盖，改成"解压到临时目录 + 原子重命名"。 先把新版本完整解到 D:\dsh.new-{GUID}，校验通过后再两次 rename 交换。这样即使中途失败，安装目录也还是完整的旧版本，不会出现"空 runtime"。
4. 静默安装也必须写 installer-logs。 10-30 那两次一条日志都没有，等于把唯一的现场销毁了。
5. 宿主侧不要把 runtime 缺失变成 fatal。 现在 dsh-skill-office 在 readFileSync 处直接把整个宿主打挂（lib/index.js:64），用户既进不去应用、也看不到日志。建议降级：office skill 标记为不可用、给一条明确的错误（"runtime 缺失，请重新运行安装包"），并提供一个自检/修复入口；至少要让应用能起来。
6. 更新器重启前再校验一次 runtime，不通过就不重启，直接把安装器失败信息展示给用户。

附：我这边的临时兜底

在找到根因之前我写了个一键"检查 + 修复"脚本，供其他遇到同样问题的用户自救：

• 检查 resources\runtime 的关键文件与文件数/体积阈值；
• 发现不完整时，用更新器缓存里的安装包（可选 sha512 校验）原位静默重装，装后复检；
• 应用还在运行则拒绝动手，避免把安装目录越搞越坏；
• 可选注册登录时的自动体检。

如果官方愿意，我可以把它整理成 PR 或直接提供脚本。

---

附件（可选，如需要我提供）：两份 fatal 日志、两份 10-17 安装器失败日志、update-info.json、resources\runtime 目录时间戳截图。

[ZiYuan258]

Third occurrence — 2026-11-04, 0.2.2-rc.1

Same bug, third consecutive release: rc.3 (10-24) → rc.5 (10-30, twice) → 0.2.2-rc.1 (11-04). Updating again emptied D:\dsh\resources\runtime, host fatal on startup, UI showed "DeepSeek Harness is unavailable". Re-running the cached installer restored it (6,144 files / 256.2 MB) and the app came back up.

New evidence from this occurrence (all timestamps local, Asia/Shanghai):

1. Same fatal, new build

%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-11-04T14-21-01-845Z-host.log:

time: 2026-11-04T14:21:01.845Z
source: host
phase: startup
app: @deepseek-ai/dsh-desktop 0.2.2-rc.1
platform: win32 x64 / electron: 44.7.0 / node: 24.21.0

DesktopHostFatalError: ENOENT: no such file or directory, open 'D:\dsh\resources\runtime\office-skills\office\SKILL.md'
    at ChildProcess.<anonymous> (file:///D:/dsh/resources/app.asar/lib/main.js:10026:49)

host diagnostic:
    at readFileSync (node:fs:483:20)
    at file:///D:/dsh/resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-skill-office/lib/index.js:64:38
    at Array.map (<anonymous>)
    at new apply (.../dsh-skill-office/lib/index.js:61:33)
    at Fiber.execute (.../cordis/lib/index.js:362:24)
    at async Fiber._reload (.../cordis/lib/index.js:677:41)
    at async main (.../dsh-desktop-host/lib/index.js:594:2)
  errno: -4058, code: 'ENOENT', syscall: 'open'

Identical to the rc.3 / rc.5 reports — only main.js line moved (3831 → 10026).

2. Timeline of the broken update

time	path	event
11-04 22:08:00–06	updater\pending\deepseek-harness-0.2.2-rc.1-win-x64.exe (293,425,336 B)	update downloaded
11-04 22:20:26–30	%APPDATA%\...\plugin-operations\operations.jsonl	8 plugin install/remove records (dsh-cost-meter 1.9.55, all failed) — unrelated to the crash, listed only because the crash log surfaces them
11-04 22:21:01	crash-2026-11-04T14-21-01-845Z-host.log	host fatal, runtime missing
11-04 22:22:52	D:\dsh\resources\runtime	recreated by the manual reinstall
11-04 22:23:22	processes	app restarted, running normally

3. The smoking gun: every file kept its old timestamp but got a new CreationTime

D:\dsh after the failed update (before manual reinstall, surviving into the reinstalled state):

DeepSeek Harness.exe    LastWriteTime 2026/11/4 17:30:40   CreationTime 2026/11/4 22:22:53
resources\app.asar      LastWriteTime 2026/11/4 17:30:40   CreationTime 2026/11/4 22:22:54
resources\runtime       LastWriteTime 2026/11/4 17:30:40   CreationTime 2026/11/4 22:22:52

i.e. the new build was written at 17:30:40 (that is the mtime baked into the package), the installer re-created the whole tree at 22:22:52 — and yet resources\runtime ended up empty at 22:21 when the host started.

4. Again zero installer logs

%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\ still contains only the two files from 2026-10-17. The 11-04 update produced no record at all, exactly like 10-30.

5. Cache payload is again fine

installer.exe                                        293,425,336 B   2026-11-04 22:08:04
pending\deepseek-harness-0.2.2-rc.1-win-x64.exe      293,425,336 B   2026-11-04 22:08:04
pending\update-info.json  {"fileName":"deepseek-harness-0.2.2-rc.1-win-x64.exe",
  "sha512":"swcK0J6ofGkaAWLRpOes2ca7CWO8vuM5Vp0FRnQ/DG3q+Z+OhvsgLz3hIiSYpRUETY+fEz+Ww86fNa0jiVIifw==",
  "isAdminRightsRequired":false}

Same package, manual run → works. So the payload is never the problem; the update path is.

6. Healthy state verified afterwards

runtime: D:\dsh\resources\runtime
files=6144   size=256.2 MB   office-skills\office\SKILL.md = present
DeepSeek Harness processes: 2 (shell + host), started 22:23:22
new crash logs after restart: none

---

Why this keeps happening (and why it will keep happening)

Three releases in a row, same failure, zero logs, and the same manual workaround. Nothing in the 0.2.2-rc.1 packaging changed the behaviour, which suggests the update path has no post-install verification at all: NSIS returns success even when it could not replace directories that the still-running app/host holds open, and the updater restarts the app regardless.

The two concrete asks, repeated from the original report and now backed by three occurrences:

1. Verify after install, before restart. If resources\runtime\versions.json, bin\, primary-runtime\ or office-skills\office\SKILL.md are missing (or file count is below ~6,000), treat the update as failed, roll back to the previous directory, return a non-zero exit code, and tell the user — do not restart into a broken install.
2. Never leave a half-replaced install directory. Extract into <install>.new-{GUID}, verify, then swap with two renames. A failed update then leaves the old, working install untouched.

Plus the two smaller ones: write installer-logs for silent installs too (three failures now have no installer-side record), and make the host degrade gracefully instead of fatal when the runtime payload is missing (dsh-skill-office/lib/index.js:64 currently kills the whole host before the UI can load, so the user cannot even see what went wrong or reach a repair entry point).

If it would help, I'm happy to test a candidate build, run a reproduction with tracing enabled, or hand over the small check-and-repair script I wrote for the community in the meantime — just say which.