DeepSeek Harness 更新后启动 ENOENT：runtime 缺失的文件校验与回填实验

更新完重启，弹「The application could not start or stopped unexpectedly」，点 Restart 还是同一句，崩溃日志里只有一行 ENOENT ... office-skills\office\SKILL.md——很容易以为少了一个文件，实际上整个 resources\runtime 目录是空的，安装包 payload 里那 6150 个文件一个都没落盘。 这类问题的关键是先做文件计数与哈希校验，分清「落盘丢了」和「打包就没带」，因为两者的处置完全不同（#10861）。

DeepSeek Harness 实验一：数文件，先分清空目录还是缺单文件

resources\runtime 目录存在但为空，是这类故障最典型的形态；目录里有几千个文件、只缺 SKILL.md，才是真的单文件问题。

1. 打开安装目录，进 resources\runtime，看文件数量。
2. 用一行命令数：(Get-ChildItem -Recurse -File).Count，记下结果。
3. 再看安装目录其它位置：社区案例里 runtime 外的 1661 个文件都在，大小与安装包一致，只有 runtime 是空的。
4. 对照安装包 payload：同一个版本包的 runtime 里有 6150 个文件，含 bin、cli、office-skills、primary-runtime、versions.json。
5. 0 对 6150，就是落盘问题，可以回填；如果安装目录里有 6150 个却仍报错，转去查单文件。

顺带排除三个常见误判：磁盘空间（案例里 D 盘剩 178 GB）、路径过长（runtime 内最长 174 字符）、符号链接（runtime 内没有）。

DSH插件 实验二：校验提取物，别拿半份文件去覆盖

回填前必须先证明拿到的是「同一版本、完整、未被改写」的 payload，否则等于把另一个问题盖上去。

1. 找缓存包：%LOCALAPPDATA%\@deepseek-ai\dsh-desktop-updater\pending\deepseek-harness-<版本>-win-x64.exe。
2. 先核对下载完整性：它的 sha512 应与 pending\update-info.json 记录一致。
3. 用 7-Zip 打开 exe，取出 $PLUGINSDIR\app-64.7z。
4. 从这个 7z 里单独解出 resources\runtime 到临时目录。
5. 校验：文件数应为 6150，总大小约 257.3 MiB。
6. 抽查关键文件：office-skills\office\SKILL.md 应存在且为 957 字节。

# 在解出的 runtime 目录里执行
(Get-ChildItem -Recurse -File).Count
(Get-Item .\office-skills\office\SKILL.md).Length
Get-ChildItem -Recurse -File | Get-FileHash -Algorithm SHA256

社区恢复成功的那次，恢复的 6150 个文件全部通过 SHA-256 校验，回填后约 24 秒看到完整会话界面，账号与会话均保留。

DeepSeek Harness 实验三：判断是不是「打包期就没带」

如果安装包里也没有这个文件，就别再折腾回填；那是构建缺件，用户侧无解。

1. 打开已安装的 Resources\app.asar，只看文件索引，不看内容。
2. 找到目标目录，比如 macOS 案例里的 @deepseek-ai/dsh-experimental-cua-macos/native/bin/，数条目数。
3. 社区实测结果是 0 条：整个 asar 索引 657 个文件里有 lib/index.js、Package.swift、23 个 Swift 源文件、测试和 schema，但 native/bin/ 下一条都没有，x64 与 arm64 都没有。
4. 对照 app.asar.unpacked/：那里装着 node-pty、koffi、sherpa-onnx-darwin-x64，说明打包器本身是会带原生载荷的，只是这个包没东西可带。
5. 再确认加载路径：prepareNativeExecutable() 只在 isSourcePackage() 命中仓库检出时才编译，否则直接 access(path, X_OK)，必然 ENOENT。
6. 结论：这是打包缺件，手工编译也不行——Info.plist 里的 ElectronAsarIntegrity 记录 asar 头哈希，塞文件会让完整性校验失败，除非重写哈希并重新签名整个包。

顺带一提，同一个案例里还叠了一个平台门槛：helper 的 README 写明只支持 macOS 14+，而那台机器是 13.7.1。打包缺失和平台不支持是两个问题，别混着推断。

DeepSeek插件 实验四：确认回填不会踩到「目录被占用」

回填和更新器改名是两件事：回填只写文件，不重命名安装目录，所以不会被 CWD 占用挡住；但更新本身失败时，先要解决的是改名那一步。

1. 若更新点完没重启、版本没变，看安装器日志里的 MoveFileExW。
2. 错误 32 表示目标目录是某个进程的当前工作目录——安装器继承了快捷方式的「起始位置」，等于给自己的 CWD 改名。
3. 错误 5 表示目录里有被打开的文件，社区案例里是一个 VS Code 工具子进程持有 resources\runtime\dli\bin 下的句柄，关掉 VS Code 后更新成功。
4. 两种错误都重试 10 次、约 60 秒后以退出码 2 中止，留下约 1 GB 的 .new-{GUID} 暂存目录。
5. 确认没有残留进程后，从 %TEMP% 这类不在安装树里的目录运行待装包即可。

DeepSeek Harness 回填操作：Robocopy 覆盖，不删别的文件

回填用镜像复制到 resources\runtime，只补缺的文件，不要动安装目录其它内容。

1. 完全退出 DSH，确认任务管理器里没有 DeepSeek Harness 进程。
2. 把实验二解出的 runtime 放到一个独立临时目录，比如 D:\tmp\runtime。
3. 执行镜像复制：robocopy "D:\tmp\runtime" "D:\herness\resources\runtime" /MIR /COPY:DAT /DCOPY:DAT /R:1 /W:1。
4. 复制完成后复核：RUNTIME_FILE_COUNT=6150、OFFICE_SKILL_EXISTS=True、Robocopy 失败文件数 0。
5. 启动应用，确认能进会话界面、菜单可交互、没有新增崩溃日志。

如果安装器在别的机器上卡在目录改名，也可以先用同一条 robocopy 思路，把 .new-{GUID} 暂存目录镜像到原安装目录，再启动。

DSH插件 注意事项

下面这些做法会加重问题或掩盖真因，先避开再谈修复。

1. 别只补那个报错的文件。SKILL.md 只是第一个被读到的文件，缺 6149 个其它文件一样跑不起来。
2. 别用不同版本的 runtime。版本不一致会引入更难查的兼容问题，务必用同一版本、同一架构的 payload。
3. 别在更新失败后反复重装。目录改名失败时重装同样会失败，先解决占用再装。
4. 别手工往 asar 里塞文件。macOS 侧会被完整性校验拒绝，这是设计而非缺陷。
5. 留下日志与校验记录。文件数、总大小、SHA-256 结果，是判断「恢复是否真的成功」的唯一依据。

如果你的安装包里 runtime 也是空的，那就不是这篇能解决的：需要重新下载完整安装包，或等官方修复打包流程。相关排查见 DeepSeek Harness 桌面端启动异常：没有窗口、启动崩溃、EMFILE 与 80 秒单核满载。