Windows: desktop updater always fails to replace the install directory (MoveFileExW error 5) and silently rolls back

[kohsah]

Summary

On Windows 11 (10.0.26300), "Install and Restart" in DeepSeek Harness Desktop fails every time:

DeepSeek Harness Setup — The installation directory could not be replaced.
Operation: MoveFileExW
Windows error: 5 (Access is denied.)
Source: C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness
Destination: ...\DeepSeek Harness.old-{GUID}
Attempts: backup: Windows error: 5 (x10)

The installer stages the new build next to the app and then renames the current install folder aside (DeepSeek Harness -> DeepSeek Harness.old-{GUID}). On Windows that rename returns ERROR_ACCESS_DENIED (5) as long as any process still has a file open inside the folder. The installer is spawned detached by the running app, so the backup step races the app's own shutdown: it fails, retries ten times, rolls back, and relaunches the old version.

The lock does not come only from DeepSeek Harness.exe. Helper processes whose image lives inside the install folder (bundled node.exe under resources\runtime\..., console hosts) keep the folder locked after the visible app window is gone.

Steps to reproduce

1. Install 0.2.2-rc.1 per-user (%LOCALAPPDATA%\Programs\DeepSeek Harness).
2. Let the app download 0.2.2-rc.3 (nightly channel).
3. Click "Install and Restart" - once at 13:19:33, again at 13:25:02.
4. Both attempts produce the dialog above; the app comes back on the old version.

Actual / Expected

Actual: the update can never install, the failure surfaces as a generic dialog, and the pending installer stays in the updater cache, so the cycle repeats on the next click.

Expected: the installer should wait until the previous version has fully exited before renaming the folder (or retry for longer / move items individually), and report a clear, actionable error instead of silently rolling back.

Evidence

• %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\directory-failure-*.log - the identical error 5 on 11/5, 11/6, 11/7 (x3), 11/10 (x2), 11/13 (x2).
• Measured with the same API on the same machine: MoveFileExW(dir -> dir.old) returns 5 when any file inside the folder is open, 32 when only a process working directory is inside it, and 0 when the folder is free.
• Killing only processes named DeepSeek Harness.exe is not enough - the folder stayed locked for minutes. Once every process rooted in the folder was terminated, the rename succeeded on the first try (0 s) and the install completed: 0.2.1-rc.5 -> 0.2.2-rc.1.

Workaround

With the app fully closed, stop every process rooted in the install folder, then run the already-downloaded installer from a neutral working directory:

Start-Process "$env:LOCALAPPDATA\@deepseek-aidsh-desktop-updater\pending\<installer>.exe" `
  -ArgumentList '--updated','--force-run' -WorkingDirectory $env:TEMP

Environment

• Windows 11, build 10.0.26300, x64
• Desktop app: 0.2.1-rc.5 -> 0.2.2-rc.1 -> (attempting) 0.2.2-rc.3
• Update channel: nightly, provider generic (app-update.yml)
• Install scope: per-user (%LOCALAPPDATA%\Programs\DeepSeek Harness)
• Installer: deepseek-harness-0.2.2-rc.3-win-x64.exe (sha512 matches update info, signature valid)

Related

Independent report of the same root cause (third-party plugin repo): OrderG-X/dsh-chrome-bridge#3

Filed as a discussion because the issue tracker is disabled on this repository.

[kohsah]

Follow-up: the blocking handle was identified (it is not one of DSH's own processes)

Re-ran the install with logging of the actual handle owners (handle64 -a), with every DSH process stopped. The folder stayed unrenamable for the full 15 minutes, and every sample showed the same single holder:

Code.exe  pid: 37204  type: File  714: ...\Programs\DeepSeek Harness\resources\runtime\cli\bin

That is VS Code (--type=utility --utility-sub-type=node.mojom.NodeService) holding a directory handle inside the install tree - a terminal/watcher on resources\runtime\cli\bin, i.e. the folder where the bundled dsh CLI lives. No DSH process was running at that point.

So the failure is not specific to DSH's own helper processes: any open handle anywhere under %LOCALAPPDATA%\Programs\DeepSeek Harness makes the "rename the old install folder aside" step fail with ERROR_ACCESS_DENIED, and the updater gives up after ~10 quick retries.

The request stands, and this makes it a bit broader:

1. Do not use a whole-directory rename as the only install strategy - or retry for much longer (a handle can legitimately live for hours, e.g. an editor with a terminal in the install tree).
2. When the backup rename fails, report which files are in use (or that the directory is in use by another process) instead of only "Access is denied" - the current dialog gives no way to find the culprit.
3. State in the dialog that other applications may hold the folder open, not just the app itself.

Workaround for anyone hitting this: close any editor/terminal/explorer window that has a folder inside the install tree open, stop all processes rooted in the install folder, then run pending\<installer>.exe --updated --force-run from a neutral working directory.

[anylink]

Root cause is the spawn order — this failure is deterministic, not a retry-window issue

Confirming #13214 from a different angle. The handle analysis above is correct, but there is a layer above it that makes the failure unconditional: the installer is spawned before the app quits, so the rename always begins at the one instant where the folder is guaranteed to be busy.

1. quitAndInstall() spawns first, quits second

resources/app.asar → electron-updater's BaseUpdater:

quitAndInstall(isSilent = false, isForceRunAfter = false) {
    const isInstalled = this.install(isSilent, isSilent ? isForceRunAfter : this.autoRunAppAfterInstall);
    if (isInstalled) {
        setImmediate(() => {
            require("electron").autoUpdater.emit("before-quit-for-update");
            this.app.quit();          // ← quit happens after spawn
        });
    }
}

install() → doInstall() ends with this.spawnLog(installerPath, args) and returns true synchronously. args is ["--updated", ...] (/S only when silent). So NSIS is already running and reaching for MoveFileExW while the app is still alive.

2. prepareInstall() only stops the node host

requireCleanStop = true;
await Promise.all([backend.stop(), stopOperationReports()]);   // stops dsh-desktop-host only
updateStoppedHost = true;
const stopFailure = updateStopFailure;
if (stopFailure !== void 0) throw new DesktopUpdatePreparationError("stop-failed", ...);
await operationJournal?.drain(500);
shellInstallerOwnsQuit = true;                                  // hand over quit

backend.stop() terminates dsh-desktop-host. main / gpu-process / utility (NetworkService) / renderer are never waited for — they can only exit after app.quit(), which fires after the spawn.

The before-quit handler itself is correct (if (shellInstallerOwnsQuit) { ...; return; } allows the quit), and the intent is clearly there. But by the time it runs, the ordering is already lost.

3. Measured on this machine

• RmRegisterResources + RmGetList against the install dir while the app runs → 5 holders, all DSH itself (main, gpu-process, utility/NetworkService, renderer, dsh-desktop-host). No third party at that moment.
• With every DSH process gone: MoveFileExW(dir → dir.old) returns 0 on the first attempt; File.Open(exe, ReadWrite, None) succeeds.
• installer-logs/directory-failure-*.log: 13 files, 10-24 → 11-13, every one Windows error: 5, Attempts: backup: Windows error: 5 ×10, Restoration error: 0. Zero successes.

So the rename outcome is fully determined by "is anything holding the folder at spawn time" — and spawn time is hard-coded to the one instant where the answer is always yes. The VS Code handle found above makes it worse, but it is not required for the failure: DSH's own four Electron processes are enough.

4. Suggested fix

App side — move the spawn out of quitAndInstall() into the quit path that is already prepared for it:

• spawn in the before-quit allow-branch (after disposing tray/dialogs), or in will-quit; or
• use the autoInstallOnAppQuit path, which installs from the quit handler with isSilent = true — its ordering is naturally correct.

Installer side — stop relying on a whole-directory rename as the only strategy:

• before MoveFileExW, poll both the process image name and open handles under the install root (not just DeepSeek Harness.exe), with a long timeout — as noted above, a handle from an editor or a terminal can legitimately live for hours;
• retry meaningfully, or fall back to per-file replacement;
• on give-up, name the blocking process/handle instead of silently rolling back.

5. Also worth fixing

desktop_update_task_inspection_timeout currently surfaces as "安装更新失败，请稍后重试。" with no hint. It fires when a task is still running. The message should tell the user to stop running tasks first, or offer a "stop tasks and update" action.

---

Environment: Windows 11 10.0.26300, per-user install under %LOCALAPPDATA%\Programs\DeepSeek Harness, nightly channel, 0.2.2-rc.2 → 0.2.2-rc.3, installer ~285 MB (electron-builder NSIS). Both failure modes reproduced on this machine; full installer logs and the Restart Manager output can be attached on request.