rc2到rc3升级点击界面安装重启后应用不重启、版本没变

[czheng5]

Summary

Clicking the "install and restart" action closes the app, but nothing is installed and the app does not come back. The version stays at 0.2.1-rc.2. The installer has downloaded and even unpacked the new build, then aborts at the directory swap.

Environment

• Windows 10.0.26300 (x64)
• DeepSeek Harness desktop 0.2.1-rc.2, updating to 0.2.1-rc.3
• Per-user install (custom install location on a non-system drive; isAdminRightsRequired: false)
• Update feed: <feed url>/win-x64/, channel nightly
• Cache: the standard electron-builder updater cache under %LOCALAPPDATA%
• Throughout below, <installDir> is the app's install directory and <parentOf installDir> is its parent

What happens

1. The update is downloaded into the updater cache: pending\deepseek-harness-0.2.1-rc.3-win-x64.exe (289,415,960 bytes). Its sha512 matches pending\update-info.json.
2. The installer runs and unpacks the complete new build into <parentOf installDir>\<installDir-name>.new-{GUID} - 7814 files / 1043 MB, and the staged DeepSeek Harness.exe is correctly versioned 0.2.1-rc.3.
3. It then tries to rename the current install dir and fails. The installer's own error dialog:

Operation: MoveFileExW
Windows error: 5 (Access denied)
Source: <installDir>
Destination: <installDir>.old-{GUID}
Restoration error: 0
Attempts:
backup: Windows error: 5
backup: Windows error: 5
... (10 attempts)

4. The installer exits with exit code 2 after ~60 s (10 retries). Nothing under <installDir> is modified - every file keeps its old timestamp. No restart is attempted.

Ruled out

• Disk space: the target drive had ~297 GB free; the payload is 276 MB.
• Permissions on the install dir: owner is the invoking user; ACL has Authenticated Users: Modify; no deny ACEs; no integrity label on the install dir or its parent; not a junction/reparse point; small-file and 276 MB write tests inside <installDir> both succeed.
• UAC: update-info.json says "isAdminRightsRequired": false; the install is per-user and the uninstaller is <installDir>\Uninstall DeepSeek Harness.exe /currentuser.
• Locked files: every DeepSeek Harness.exe process (GUI, host and tool runners) was stopped and the count was verified to be 0 before the installer ran; no other process had any module/path loaded from <installDir>.
• Elevation: running the installer from an elevated shell does not change the outcome.

Additional observation (possibly the key)

The same rename fails manually while the app is fully stopped:

Rename-Item '<installDir>' '<installDir-name>.probe'        # -> "Access to the path is denied." (Win32 5)
Rename-Item '<installDir>.new-{GUID}' '<installDir-name>-new'   # -> works

So the failure is specific to that one directory, not to renames in general, and we could not identify a handle holder for it. A sibling directory renames fine. This suggests something about <installDir> (or a file inside it) that only the directory-rename path trips over.

Workaround that works

With the app stopped, mirror the staged build over the install dir:

robocopy '<installDir>.new-{GUID}' '<installDir>' /MIR /COPY:DAT /DCOPY:DAT /R:1 /W:1

The app then starts 0.2.1-rc.3 from the original path. This is how the update was finally applied.

Suggestions

1. If the backup rename fails, fall back to an in-place file overwrite (robocopy-style) instead of aborting - this environment can never complete the swap.
2. Surface the failing operation and Win32 error in the update UI (the installer's dialog is the only place the real error is visible; the app itself just closes).
3. Clean up the staged <installDir>.new-{GUID} directory after a failed update (it is a full 1 GB build left behind).
4. Log the pre-flight checks (target dir writable, target dir renamable) to a file that support can ask for.

[751496032]

一样的情况

[pitigre-fan]

还以为是我的问题

[dusollst]

一样的情况，我本地让dsh写了个脚本我来手动更新的。
全局诊断报告如下↓

GitHub 回复稿（DeepSeek Harness · Discussions）

目标位置：#10930
（同症状帖："rc2到rc3升级点击界面安装重启后应用不重启、版本没变"，9 小时前，作者 czheng5，已有 2 条"我也是"回复）
说明：该仓库 Issues 已关闭（has_issues: false），Bug 走 Discussions；同批还有
#10851（error 5 → 就地覆盖、数据丢失）
和 #10973（卡在"正在准备重启…"）。
建议回帖到 #10930，不另开新帖。

Same symptom, different Win32 code — root cause identified: the installer inherits the install directory as its own working directory (error 32, not 5)
I hit the same rc.2 → rc.3 behaviour (app closes, nothing installs, version stays 0.2.1-rc.2), but the installer log here shows a different Win32 code, and the holder of the directory can be named.

Evidence (Windows 11 26100, per-user install to D:\Program Files\DSH, nightly channel)

1. installer-logs/directory-failure-*.log — three attempts (2026-10-24 13:32, 2026-10-25 00:27, 2026-10-25 07:10 local), all identical:

Operation: MoveFileExW
Windows error: 32 (另一个程序正在使用此文件，进程无法访问。)
Source: D:\Program Files\DSH
Destination: D:\Program Files\DSH.old-{GUID}
Restoration error: 0
Attempts:
backup: Windows error: 32   ×10

2. The staged build is complete: D:\Program Files\DSH.new-{F735AA26-...} — 1043 MB / 7814 files, and its resources\app.asar really is 0.2.1-rc.3 (dshBuildCommit: be72761e…). So this is not a download, checksum or signature problem.
3. The holder is the installer itself. The Desktop and Start Menu shortcuts have Start in = D:\Program Files\DSH, so the shell starts with that working directory; reading each running DSH process's PEB (RTL_USER_PROCESS_PARAMETERS->CurrentDirectory) gives D:\Program Files\DSH\ for all three processes. electron-updater's BaseUpdater.spawnLog() calls spawn(cmd, args, { stdio, env, detached: true }) without cwd, so the NSIS installer inherits D:\Program Files\DSH and then tries to rename that very directory ($INSTDIR → $INSTDIR.old-{GUID}).
4. The app itself was already gone at swap time: writes under %APPDATA%\@deepseek-ai\dsh-desktop stop at 07:09:46 and only resume at 07:41:49 (manual relaunch), so no DSH process was standing in the directory when the rename was retried.
5. Mechanism verified locally (same Windows build):
   | scenario | result |
   | --- | --- |
   | rename a directory that is some process's CWD | 0x80070020 = Win32 32 (same message as the installer log) |
   | rename a directory that merely has an open file inside | Win32 5 (access denied) |
   That split also explains why this report sees 32 while rc2到rc3升级点击界面安装重启后应用不重启、版本没变 #10930 / [Bug] Windows auto-update to 0.2.1-rc.3 overwrites install dir D:\dsh and deletes workspaces stored inside it (data loss) #10851 see 5 — different lock sources behind the same "update does nothing" symptom.
6. Consequence: 10 retries over ~30 s → installer aborts, restores the old tree (Restoration error: 0), does not relaunch (--force-run is never reached) → UI just closes, version unchanged, and a 1 GB DSH.new-{GUID} is left behind (they also pile up: updater cache holds another 553 MB here).

Fix

• electron-updater / doInstall: pass a cwd outside the install tree, e.g. cwd: app.getPath('temp'); or have the NSIS installer SetCurrentDirectory $TEMP before the .old-{GUID} swap.
• Surface installer failure to the next launch (the shell has already quit, so today nothing is shown) and offer "retry install".
• Clean up .new-{GUID} / .old-{GUID} after success and failure.
• Shortcuts created by the installer should not set Start in to the install directory.

Workaround that worked here

Quit DSH completely (no DeepSeek Harness.exe), then run the downloaded installer from a shell whose CWD is not the install directory:

Set-Location $env:TEMP
& "$env:LOCALAPPDATA\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.1-rc.3-win-x64.exe" --updated --force-run "/D=D:\Program Files\DSH"

(also: change the two shortcuts' Start in to %USERPROFILE%, otherwise the next in-app update hits the same trap.)

中文摘要（可只贴这段，或与上面一起）

rc.2 → rc.3 应用内更新失败的第二种成因，与 #10930 的 error 5 不同：本机日志是 Windows error 32（文件被占用）。原因是安装器自己的工作目录就是 D:\Program Files\DSH——快捷方式"起始位置"是该目录，electron-updater spawn 安装器时不传 cwd，NSIS 安装器于是继承了它，再去把这个目录改名做备份，等于给自己的 CWD 改名，必然被拒（本机对照实验：CWD 被占 → 32；仅文件被打开 → 5，与日志完全对应）。切换发生时应用其实已经退出，安装器重试 10 次后中止，还原旧目录、不重启（--force-run 走不到），所以表现为"点了重启没反应、版本没变"，并留下 1 GB 的 .new-{GUID} 残留。
建议修法：spawn 安装器时显式给 cwd（如 %TEMP%），或 NSIS 在改名前置 SetCurrentDirectory $TEMP；失败要能让下次启动看到；清理 .new-{GUID}。
临时绕法：完全退出 DSH 后，在 %TEMP% 里运行缓存中的安装器（命令见上），并把快捷方式"起始位置"改成 %USERPROFILE%。

[tjumao]

[Windows] Update to 0.2.1-rc.3 fails with MoveFileExW ERROR_ACCESS_DENIED (5); update succeeds after closing VS Code

Summary

I encountered a repeatable Windows update failure when upgrading DeepSeek Harness from 0.2.1-rc.2 to 0.2.1-rc.3.

The installer repeatedly failed to rename the existing installation directory to its .old-{GUID} backup directory. The error was MoveFileExW, Windows error 5 (Access is denied), with 10 failed backup attempts.

During investigation, Windows Resource Monitor showed a Code.exe process holding a file handle under the Harness installation directory. The process was a VS Code utility subprocess, not the Harness main executable. After closing VS Code and retrying the update, the update completed successfully.

This strongly suggests that an external process holding a file under the installation directory may prevent the directory swap. However, I cannot conclusively establish that this specific handle was the sole cause, because the update was retried after closing VS Code.

Environment

• OS: Windows 11, build 26200 (10.0.26200)
• DeepSeek Harness: 0.2.1-rc.2 → 0.2.1-rc.3
• Installation directory: D:\app\deepseek
• Installer: deepseek-harness-0.2.1-rc.3-win-x64.exe
• Update method: downloaded updater-cache installer, launched directly after reboot
• Installation drive: NTFS, healthy, with approximately 201 GB free

Error log

The failure occurred repeatedly, including at 2026-10-26 14:08:59:

Operation: MoveFileExW
Windows error: 5 (Access is denied.)
Source: D:\app\deepseek
Destination: D:\app\deepseek.old-{93F3EB93-971A-4A0D-AF5E-F00007C52EC9}
Restoration error: 0
Time: 2026-10-26 14:08:59
Windows: 10.0.26200
Attempts:
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5
backup: Windows error: 5

The same failure persisted after reboot and when launching the cached installer directly.

Investigation and evidence

1. The suspected process was VS Code

Windows Resource Monitor showed the following process associated with a file handle under the Harness installation directory:

Process: Code.exe
PID: 21248
Path: D:\app\Microsoft VS Code\Code.exe
Command line:
--type=utility
--utility-sub-type=node.mojom.NodeService

The associated file path was under:

D:\app\deepseek\resources\runtime\dli\bin

The process was a VS Code utility subprocess, with another Code.exe process as its parent.

2. Other checks did not reveal an obvious permissions or disk problem

• The installation directory was a normal directory, not a reparse point.
• ACL checks and icacls /verify did not reveal an obvious permissions problem.
• NTFS reported a healthy volume.
• Renaming ordinary test directories, including a directory containing files, succeeded.
• Windows Defender logs did not show a corresponding block event.

These checks do not rule out every possible security or filesystem cause, but they make a simple directory-permission problem less obvious.

3. Closing VS Code was followed by a successful update

After identifying the handle, I closed VS Code and retried the update. The update completed successfully.

This is strong circumstantial evidence of a file-handle conflict involving another process, but further investigation is needed to establish the exact cause.

Expected behavior

When an update cannot rename the installation directory, the installer should:

1. Identify or provide diagnostics for processes holding files under the installation directory, where technically possible.
2. Record the affected file path and process details in the failure log.
3. Clearly tell the user which application should be closed before retrying.
4. Abort safely if the backup rename fails, rather than proceeding with a potentially unsafe in-place replacement.
5. Consider waiting for relevant child processes and runtime helpers to exit before attempting the directory swap.

Questions for maintainers

1. Can the updater or one of its runtime components cause VS Code or an extension to access files under resources\runtime\dli\bin?
2. Does the installer currently check only the Harness main executable, potentially missing external processes that hold files inside the installation directory?
3. Could the installer use Windows Restart Manager or another diagnostic mechanism to identify processes preventing the directory rename?
4. Could the update process defer the directory swap until all relevant handles have been released?

Additional context

This may be related to other reports of Windows updates failing at the directory-backup stage with MoveFileExW error 5. I am sharing this case because it includes a concrete process-level observation and a successful workaround that may help narrow down the cause.

I can provide additional logs or command output if needed.