Upgrade installer silently deletes a workspace that lives inside the install directory (Windows)

[AnceriseLeah]

Summary

Severity: permanent data loss — silent, unrecoverable, triggered by the normal upgrade path.

On Windows, upgrading to 0.2.1-rc.2 via the official installer permanently deleted a DSH workspace directory because that workspace happened to live inside the previous install directory. The app was fully closed during the successful upgrade — i.e. the normal, recommended flow (quit the app, run the installer). There was no warning, nothing went to the Recycle Bin, and the data is unrecoverable on an SSD with TRIM enabled.

A workspace is where users keep everything they create with DSH — documents, code, datasets, drafts. Losing it is not recovering from a bad cache; it is losing weeks of work.

Related: #8354 (same Windows installer, false "app cannot be closed" detection).

Environment

• Windows 11 (build 26200), x64
• DeepSeek Harness 0.2.1-rc.2, official Windows installer
• Previous version installed into a custom directory on a non-system drive, e.g. <InstallDir>
• Workspace was selected inside that directory: <Workspace> = <InstallDir>\work area

What happened

1. The previous version lived in <InstallDir> (a user-chosen install location). A DSH workspace <InstallDir>\work area was created and used inside it.

2. A first upgrade attempt produced this log under %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\directory-failure-<timestamp>.log:

   Operation: MoveFileExW
   Source: <InstallDir>
   Destination: <InstallDir>.old-{GUID}
   Windows error: 5 (Access is denied)
   Attempts:
   backup: Windows error: 5      (repeated ~8 times)
   

   That attempt aborted (installer exit code 2) because DSH was still running. It matters for one reason only: it reveals the installer's upgrade strategy — rename the previous install root to .old-{GUID}, then remove it.

3. DSH was then fully quit, and the installer was run again. This time it succeeded and installed into %LOCALAPPDATA%\Programs\DeepSeek Harness.

4. Immediately before that successful run, the workspace still existed — the user confirmed it was intact while quitting the app. After the install, <InstallDir> — including <Workspace> — was gone: with nothing holding the directory, the rename to .old-{GUID} succeeded silently and the renamed tree was then deleted. No .old-{GUID} remained, nothing appeared in the Recycle Bin, no restore point existed.

5. Every session bound to that workspace then failed with:

   working-directory: directory does not exist: "<Workspace>"
   

   and the app recreated <Workspace> as an empty directory, so it presents as "my project is empty" rather than a loud error.

Mechanism (from the project's own documentation)

apps/desktop/README.md describes the uninstall behaviour: an uninstaller started with --updated or /KEEP_APP_DATA — "as electron-builder does for in-place updates and for replacing an older installation from another directory" — retains $DSH_HOME, and the native remover "refuses protected Windows folders and paths overlapping the installation or the home".

So user data is protected in exactly one place: $DSH_HOME (~/.dsh). Anything else that happens to sit inside the installation directory — here, the workspace — is inside the tree being removed, and no rule covers it.

That is what makes this a data-loss bug rather than an installer quirk: the protection model covers the app's home directory, not the user's workspace, and nothing warns the user that the difference exists.

Impact

• All user-created files in the workspace were lost: source files, documents, notes, generated assets.
• Not recoverable in practice: NTFS with TRIM enabled (fsutil behavior query DisableDeleteNotify → 0), so deleted blocks are already discarded by the drive. winfr / Recuva find nothing.
• The failure is silent and only discovered after the upgrade completes, when the user tries to continue working.
• The destructive path is the clean one. Nothing needs to go wrong: quit the app (so the directory is no longer locked), run the installer, accept the default install location — and the old install root, workspace included, is renamed and deleted. The error: 5 episode above is a failed attempt, not a precondition.
• This is not specific to one setup: any user who picks a custom install directory and keeps a workspace inside it (a very natural thing to do — the installer asks where to install, and DSH asks where the workspace is) will hit the same outcome on the next upgrade.

Why it matters beyond one user

• The workspace is the product's core data location. Users are explicitly encouraged to point DSH at a project folder. Nothing in the UI or docs says "never put the workspace inside the app directory".
• Upgrade-time directory replacement plus recursive delete is a destructive combination, and it runs against a directory the app itself told the user to choose.
• The loss is irreversible and unannounced, which is the worst combination for user trust.

Suggested fixes (in rough order of value)

1. Never recursively delete a directory the installer did not fully create. When renaming/removing the previous install root, delete only known payload paths (DeepSeek Harness.exe, resources/, locales/, …). Leave anything else in place.
2. Pre-upgrade check: if any registered workspace path is inside the install directory, show a blocking warning before touching anything: "This workspace is inside the installation folder and will be removed. Move it first." Offer to relocate.
3. Workspace picker warning: if the chosen folder is inside the app's install directory (or its parent), warn at selection time and once at startup.
4. Missing workspace handling: when a session's working directory does not exist, show an explicit error, and do not silently recreate an empty directory that makes the workspace look empty-but-fine.
5. Docs: add a one-line hard rule to the Safety / getting-started docs — keep workspaces outside the installation directory.

Reproduction outline

1. Install DSH into a custom directory <InstallDir> on a non-system drive.
2. Create a workspace at <InstallDir>\work area, add files, run sessions.
3. Fully quit DSH (tray icon → Exit), so nothing holds the directory.
4. Run the newer installer and let it install to the default location.
5. Observe: <InstallDir> is removed together with the workspace (no .old-* left behind, no Recycle Bin entry), and sessions in that workspace fail with working-directory: directory does not exist.

---

中文摘要

在 Windows 上，从旧版本升级到 0.2.1-rc.2 时，安装器把位于安装目录内的工作区连同旧安装目录一起删除了：无提示、不进回收站、SSD 已开 TRIM 无法恢复。工作区是用户所有创作文件所在处，这相当于无声地删掉用户数周的工作。

触发条件不需要任何异常：正常流程就是「退出 DSH → 运行安装器 → 用默认位置」。程序关着恰恰是危险所在——目录不再被占用，安装器可以顺利把旧安装目录改名为 .old-{GUID}，装完后连带删除，工作区一起消失。

日志里的 MoveFileExW <安装目录> → <安装目录>.old-{GUID}、Windows error: 5、重试约 8 次，是另一次失败的尝试（当时 DSH 还开着，目录被占用，安装器退出码 2）。它只说明了一件事：安装器的升级策略是先改名旧安装目录、再删除。

官方文档 apps/desktop/README.md 写明：从另一个目录替换旧安装时，会走旧版卸载器；该卸载器只保证不碰 $DSH_HOME（~/.dsh），以及拒绝与安装目录或 home 重叠的路径。工作区放在安装目录里，正落在被删除的树内，没有任何规则保护它。

建议：① 升级时只删除安装器自己装的文件，不递归删除整个目录；② 升级前检测「工作区是否位于安装目录内」并阻止/提示迁移；③ 选择工作区时给出警告；④ 会话的工作目录不存在时明确报错，而不是静默重建一个空目录；⑤ 文档里写死一条规则：工作区不要放在安装目录内。

这条不是个例：任何把工作区放在安装目录里的用户，正常升级一次就会中招。

[AnceriseLeah]

Adding the installer log, with absolute paths redacted.

Time: 2026-10-18 20:30:13 (first, aborted attempt — app still running)
Windows: 10.0.26200

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

Timeline from the same machine (local time):

• 20:59:34 — new version installed into %LOCALAPPDATA%\Programs\DeepSeek Harness (directory creation time); the app had been fully quit before this run
• 21:01:44 — first session turn in <Workspace> fails with working-directory: directory does not exist: "<Workspace>"
• 21:04:28 — same failure again

Nothing else touched <InstallDir> between those points.

Correction to the post: the retry count above is 10, not ~8.

[AnceriseLeah]

补充几点，方便定位问题。

一、关于上面那段日志

那是一次失败的尝试：应用还开着，目录被占用，MoveFileExW 返回 error 5，安装器中止了。真正删掉目录的是之后那次——应用完全关闭、目录不再被占用，那次没有留下日志。

所以“旧安装根目录被改名为 .old-{GUID}、然后被删除”这一步，是从结果反推的，不是日志观测到的。这点说明白，免得被当成“安装器检测到占用就安全退出”。

二、没有在新版复测

报告针对 0.2.1-rc.2。之后没再试——复测意味着再毁一个工作区，我不打算做第二次。

但升级器日志显示，“改名旧目录 → 递归删除”是无条件执行的，与技术版本无关。所以真正的问题是：这个行为现在有没有改。

三、想确认一件事

当前的安装程序，升级时是否仍然把旧安装根目录改名为 .old-{GUID} 再递归删除？

还是已经改成只删除自己安装的文件（DeepSeek Harness.exe、resources/、locales/ 等），保留目录里其他内容？

如果是前者，那么任何把工作区放在安装目录里的用户，正常升级一次就会中招——不需要任何异常操作，这也是我觉得它比普通安装器问题更严重的原因。

另外，同类报告不止我一个（另有用户在别处反馈过相同失效模式），所以这不是个例配置问题。