DSH Windows Updater: Error 5/32 & Data Safety

DeepSeek Harness Desktop update failures on Windows have several distinct paths. Recent community cases cover four of them: an installer inherits the old application directory as its current working directory and hits Error 32; a silent install lacks elevation and hits Error 5; a user stores DSH_HOME or a Workspace under the install directory and loses it when that directory is replaced; and a failed rollback leaves a .new directory behind.

They share one boundary: the application directory is replaceable program material. User data and live process state must remain outside it.

Error 32: the window closed but the directory is busy

In one reproduction, the application launches the installer with a current working directory inside the old installation. After the main process exits, Windows can still treat that directory as in use. Renaming it to a backup fails with Error 32, and retries cannot change the inherited cwd.

The updater should launch the installer with an explicit working directory under the system temporary path and release child processes, logs, watchers, and file handles. Testing must cover the case where the main window is gone but a directory handle remains.

Error 5: silent updates and elevation

Writing under Program Files normally requires elevated rights. A community report describes nightly feed metadata that did not express isAdminRightsRequired correctly, so the silent installer ran without sufficient rights and returned Error 5.

Feed metadata, package configuration, and launch arguments must agree on elevation. Before changing files, the installer should determine whether the target is protected, whether the current token can write, whether UAC can be requested safely, and whether the old version remains runnable after failure.

Why a Workspace must not live in the install directory

NSIS and directory-swap updaters may rewrite, rename, or remove the old application directory. A Workspace, DSH_HOME, Session store, credential store, or attachment directory placed underneath it is indistinguishable from obsolete program files.

One case stored a custom DSH_HOME inside the install root. The upgrade removed the data and DSH created a new empty home, making the result look like every Session had vanished. Another placed a Workspace under the application directory, exposing project files to old-directory cleanup.

The boundary should be explicit:

• the application directory contains reinstallable binaries and static assets only;
• DSH_HOME uses an independent, backup-ready user-data path;
• Workspaces use user-managed project directories;
• the updater stops before replacement when a data path resolves under the install root.

A Windows release test matrix

Test a regular user directory, Program Files, a custom path, a path containing spaces, a running old version, a terminal holding the install directory, misplaced DSH_HOME, and rollback after an injected failure.

For every scenario, verify that:

1. installer cwd is outside the replaceable directory;
2. elevation metadata matches the target path;
3. the complete process tree and handles are released;
4. data-path preflight blocks a dangerous upgrade;
5. the old version remains runnable after failure;
6. Sessions, credentials, plugins, and Workspace contents remain unchanged.

Before upgrading, users should confirm the resolved DSH data and Workspace paths, then back them up. Move and verify any path underneath the application directory before running the updater.

References

• Community reproduction of inherited cwd causing Windows Error 32
• Community case of DSH_HOME inside the install directory
• Upgrade risk for a Workspace inside the install directory
• Program Files silent update and Error 5

FAQ

Why does Error 32 appear after the app has closed?

A closed window does not prove that child processes, file handles, or an inherited current working directory have been released.

Can DSH_HOME be placed beside the install directory?

An independent sibling directory is acceptable; it must not resolve inside the application root that the updater replaces.

Can I delete a leftover .new directory immediately?

First verify that the old version starts and inspect the exact path. The directory may contain an incomplete new version, so avoid broad deletion without a backup.