DSH Windows 更新器安全升级
DeepSeek Harness Windows 更新器：Error 5/32 与数据安全
- 作者
- DeepSeekAgent.io 编辑部
- 发布
- 更新
DeepSeek Harness Desktop 在 Windows 上的升级问题并不只有一种。近期社区案例把四条故障链放到了一起：安装器继承旧程序目录作为当前工作目录，触发 Error 32；静默安装缺少管理员权限，触发 Error 5；用户把 DSH_HOME 或 Workspace 放在安装目录内，旧目录被替换时数据一起消失；失败回滚后还可能留下 .new 临时目录。
这些现象共享一个边界：安装目录属于可替换的程序资产，用户数据和当前进程状态必须与它分离。
Error 32：进程退出了，目录仍被占用
社区复现中的更新器从应用内启动安装程序，安装器继承了位于旧安装目录下的当前工作目录。主进程退出后，Windows 仍可能认为该目录正在被进程使用。安装器尝试把旧目录重命名为备份时得到 Error 32，等待和重试都无法改变继承的 cwd。
更可靠的实现是在启动安装器时显式把工作目录设置到系统临时目录，并确保所有子进程、日志句柄和文件监听器已经释放安装目录。验证应覆盖“主进程已退出但目录句柄仍存活”的情况，而不只检查窗口是否关闭。
Error 5：静默更新与管理员权限
如果 DSH 安装在 Program Files，写入目录通常需要提升权限。社区案例指出，某些 nightly feed 元数据没有正确表达 isAdminRightsRequired，静默安装器因此在普通权限下运行，复制文件时返回 Error 5。
更新源、安装包和调用参数需要对权限要求达成一致。安装器在真正写入前应完成预检：目标目录是否受保护、当前令牌是否拥有写权限、能否安全触发 UAC，以及失败时是否保留旧版本可启动。
安装目录为什么不能存 Workspace
NSIS 或目录交换式更新通常会重写、重命名或删除旧安装目录。若用户把 Workspace、DSH_HOME、Session、凭据或附件放在该目录内，更新器会把它们当成旧程序文件处理。
一个案例中，自定义 DSH_HOME 位于安装目录；升级后原数据被移除，应用又创建了一个空的 dsh-home，看起来像“所有会话突然清空”。另一个案例直接把 Workspace 放在应用目录下，旧目录清理时项目文件也面临删除风险。
安全规则应非常明确：
- 程序目录仅保存可重新安装的二进制和静态资源；
DSH_HOME放在独立、可备份的用户数据目录；- Workspace 放在用户明确管理的项目目录；
- 更新器发现数据目录位于安装根目录下时，必须停止并提示迁移，不能继续覆盖。
发布一次 Windows 更新前要测什么
建议维护一组安装矩阵：普通用户目录、Program Files、自定义路径、带空格路径、运行中的旧版本、安装目录被终端占用、DSH_HOME 错放在安装目录，以及升级失败后的回滚。
每个场景都检查：
- 安装器
cwd不在待替换目录； - 权限元数据与目标路径匹配；
- 进程树和文件句柄完全释放；
- 数据目录预检能阻止危险升级；
- 失败后旧版本可启动，临时目录可识别并安全清理；
- Session、凭据、插件配置和 Workspace 内容保持原样。
用户准备升级时，先在 DSH 设置中确认数据目录与 Workspace 的实际路径，再做备份。若任何路径位于安装目录内，应先迁出并验证新位置，而不是直接运行更新器。
参考资料
- 安装器继承 cwd 导致 Windows Error 32 的社区复现
- 自定义 DSH_HOME 位于安装目录导致数据丢失的社区案例
- Workspace 位于安装目录的升级风险
- Program Files 静默更新与 Error 5
常见问题
应用已经关闭，为什么仍然出现 Error 32？
窗口关闭不代表目录句柄、子进程或继承的当前工作目录已经释放。需要检查完整进程树和安装器 cwd。
可以把 DSH_HOME 放在安装目录旁边吗？
可以放在独立的同级目录，但不能位于更新器会替换的安装根目录之内。升级前应确认真实解析路径。
更新失败后看到 .new 目录，可以直接删除吗？
先确认旧版本可正常启动并核对目录内容。临时目录可能包含未完成的新版本，不应在没有备份和路径确认时批量删除。