[Bug] Windows auto-update to 0.2.1-rc.3 overwrites install dir D:\dsh and deletes workspaces stored inside it (data loss)

[wangyinhao447-sudo]

Summary

In-place Windows desktop auto-update 0.2.1-rc.2 → 0.2.1-rc.3 (2026-10-24, ~14:20 local time, UTC+08:00) destroyed the install directory D:\dsh and everything else that lived inside it.

The updater first tried to back up the install directory by renaming it: D:\dsh → D:\dsh.old-{BDFE85A7-...}. That rename failed 10 times with Windows error: 5 (access denied) because the running DSH process holds the directory open (see the installer log in Evidence §1). Instead of aborting, the updater continued and replaced D:\dsh in place, deleting every top-level entry that was not part of the new build — including the workspaces I had opened inside the install directory:

• D:\dsh\code — main project workspace (scripts, notes, release tooling)
• D:\dsh\learn — scratch workspace (MATLAB/有限元 experiments)
• D:\dsh\system environment — environment documentation + helper scripts (ENVIRONMENT.md, probes)

Nothing is recoverable: there is no D:\dsh.old-* directory, no Recycle Bin entry, no Volume Shadow Copy, no restore point. The data is simply gone.

中文摘要：Windows 桌面版自动更新 0.2.1-rc.2 → 0.2.1-rc.3 时，安装器先把安装目录 D:\dsh 改名为 D:\dsh.old-{...} 做备份，因运行中的 DSH 占用目录而失败（Windows error 5，连续 10 次）；安装器没有中止，而是改为就地覆盖安装，把安装目录里除新版本文件外的所有内容删掉——包括建在该目录下的三个工作区（D:\dsh\code、D:\dsh\learn、D:\dsh\system environment）。无 .old 备份目录、回收站无记录、无卷影副本/还原点，数据不可恢复。期望行为：备份改名失败就中止更新并提示用户关闭应用，且更新不得删除非本安装器写入的文件。

Steps to reproduce

1. Windows 10 (10.0.19045) x64, DSH desktop 0.2.1-rc.3 installed into a custom directory D:\dsh (nightly channel; the installer lets you choose the directory — upgrading from 0.2.1-rc.2 in place).
2. Register/open workspaces inside the install directory, e.g. D:\dsh\code, D:\dsh\learn, D:\dsh\system environment. The workspace picker accepts any path, so this is legal and there is no warning that it is unsafe.
3. Leave DSH running. The in-app updater downloads deepseek-harness-0.2.1-rc.3-win-x64.exe (289,415,960 B, isAdminRightsRequired=false) into %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\ and launches installer.exe while DSH is still running.
4. The installer fails to rename the install directory (locked by the running app) and installs over it anyway.

Expected behavior

• If the "rename install dir to {dir}.old-{guid}" backup step fails, the update must abort and ask the user to fully quit DSH and retry (or defer the update to app shutdown).
• An update must never delete files it did not install. User data under the install root must be preserved or the install must refuse to proceed.
• At minimum, warn before updating if workspaces are located inside the install directory.

Actual behavior

• The backup failure is logged as Operation: MoveFileExW / Windows error: 5 with Attempts: backup ... ×10, and then the updater proceeds destructively.
• D:\dsh is overwritten in place at 14:21:59; the three workspace directories are deleted with it.
• The backup destination D:\dsh.old-{BDFE85A7-A3F0-40BA-8119-B100A2CD5E44} does not exist afterwards, so the "backup" safety net never materialized.
• No prompt, no warning, no recovery path.

Environment

item	value
DSH desktop version before update	0.2.1-rc.2
DSH desktop version after update	0.2.1-rc.3 (@deepseek-ai/dsh-desktop 0.2.1-rc.3, dshBuildCommit: be72761ee1a6736ebcdf4f3739363b083ae53c98, dshBuildDirty: false)
update channel	dshDesktopUpdateChannel: nightly
install directory	D:\dsh (custom, non-default location, upgraded in place)
OS	Windows 10 Pro 10.0.19045 (22H2), x64
Electron	44.7.0 (D:\dsh\version)
installer	deepseek-harness-0.2.1-rc.3-win-x64.exe, 289,415,960 B, SHA-256 1e3876baaa20c3f26371dba7b6873bb70c3ef9b91403f6d3f87d2b27d4fd1e3a
installer requires admin	false (isAdminRightsRequired: false in pending/update-info.json)
app id	com.deepseek.dsh

Timeline (local time, UTC+08:00, 2026-10-24)

time	event
14:09:38	updater writes current.blockmap (download resumed)
14:12:31	installer.exe + deepseek-harness-0.2.1-rc.3-win-x64.exe written to the pending dir
14:12:34	pending/update-info.json written
14:20:32	MoveFileExW backup failure, Windows error 5, 10 attempts (installer log)
14:21:59	D:\dsh contents replaced in place by the 0.2.1-rc.3 build
14:22:27	new build starts; workspaces already gone

Evidence

1. Installer log: installer-logs/directory-failure-20261024-142032.log

Operation: MoveFileExW
Windows error: 5 (拒绝访问。)
Source: D:\dsh
Destination: D:\dsh.old-{BDFE85A7-A3F0-40BA-8119-B100A2CD5E44}
Restoration error: 0
Time: 2026-10-24 14:20:32
Windows: 10.0.19045
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

2. Workspaces registered inside the install directory at the time

From the pre-update copy of C:\Users\<user>\.dsh\storages\workspace.json:

"path": "D:\\dsh\\code",              // title: "code"        — 12 sessions
"path": "D:\\dsh",                    // title: "dsh"         — 13 sessions
"path": "D:\\dsh\\system environment", // title: "system environment" — 8 sessions
"path": "D:\\dsh\\learn"              // title: "learn"       — 11 sessions

3. Session logs recorded those directories as the working directory

First event of C:\Users\<user>\.dsh\sessions\--D-workplace-code--\session-6c832e96-...\session.v4.jsonl.zstd:

{"type":"session","cwd":"D:\\dsh\\code", ...}

(Copies of the logs were hard-linked to the new slug directories after the incident, so the path in the directory name now reads D:\workplace; the recorded cwd still says D:\dsh\code.)

4. Install directory after the update

D:\dsh contains only the 0.2.1-rc.3 payload (DeepSeek Harness.exe, resources/, locales/, version). The three workspace directories are gone, and D:\dsh.old-{...} was never created. See install-dir-listing.txt in the attachments.

Suspected cause

1. The Windows update path performs a "rename directory to {dir}.old-{guid}, then install" transaction. When the rename fails (running app keeps handles open inside it), the failure is treated as non-fatal.
2. The fallback is an in-place overwrite that only knows about its own payload: anything else at the install root is removed.
3. DSH allows workspaces (and therefore arbitrary user data) anywhere on disk, including inside the install root, with no guard for either the updater or the data owner.

This is a data-destroying failure mode where a recoverable precondition (app running) turns into unrecoverable loss.

Suggested fixes

1. Fail closed: on backup failure abort the update, keep the old install, and show "close DSH completely and retry the update".
2. Never delete foreign files: enumerate unknown top-level entries under the install root and preserve them (move aside or leave), or refuse to update when the root contains user data.
3. Detect the running app before touching the install dir (check for the process / locked path) and require a graceful shutdown instead of retrying blindly.
4. Consider side-by-side versioned installs (D:\dsh\0.2.1-rc.3... + junction/shortcut) so the previous version stays intact until the new one boots successfully.
5. Warn in the app if any workspace is located under the install directory, and mention that on Windows you must quit DSH before updating.
6. Log the actual list of deleted entries so support can assess damage.

Workaround for other users

• "Fully quit DSH (tray → Quit, confirm no DeepSeek Harness.exe in Task Manager) before installing an update, or update from a fresh launch when the app prompts you."
• Keep workspaces outside the install directory (e.g. D:\workplace...).
• Keep a separate copy of important workspaces; this release's updater can wipe the install root.

Attachments

• directory-failure-20261024-142032.log — installer backup-failure log (verbatim)
• update-info.json — pending update metadata (fileName / sha512 / isAdminRightsRequired)
• workspace.json.before-migration — pre-update workspace registry (paths inside D:\dsh)
• session-cwd-evidence.txt — session log excerpt proving the workspace path
• install-dir-listing.txt — D:\dsh contents after the update
• installer-sha256.txt — SHA-256 of the downloaded installer
• (all of the above also packed as bug-report-evidence.zip)

[amisha3212]

That’s a serious updater bug. If the backup rename fails because the app is still running, the installer should abort instead of continuing with an in-place update that can delete user data. Keeping workspaces inside the install directory may not be ideal, but the updater should still handle that situation safely and warn users before proceeding.

For now, fully quit DSH before updating and keep workspaces outside the installation folder, with separate backups of important files. Also, Windows 10 support ended on October 14, 2025, so users looking for a download Windows 10 ISO should use Microsoft’s official download page rather than modified ISOs from unknown sources.

for more visit: https://bagas31.pw/windows-10-pro-gratis-jan26-v1