[Bug] Data dir re-initialized during 0.1.7-rc.1 → rc.2 upgrade (Windows): all sessions / history / plugin state lost — forensics + reproduce commands attached

[mylastfree]

Evidence package (raw timestamps, logs, upgrade-helper snapshot, reproduce commands):
https://gist.github.com/mylastfree/855d7ad3d4d3ebc9f9041502f16a531e

中文摘要：2026-09-26 02:32–02:36（本地）之间，$DSH_HOME（C:\Users\16336\.dsh）下的 sessions / storages / dsh-usage / task-board / profiles 被整体重建，全部历史对话、插件状态、用法账本丢失，只剩 1 个当天新建的会话；唯一幸存的是 memory/memory.db（251 MB，2026-08-26 创建，未被改动）。当天的 rc.1 → rc.2 升级助手脚本自己声明 session data: skipped by design (V3->V4 restore is non-destructive)，而它的备份目录 dsh-backup-* 与日志目录 dsh-upgrade-logs 都从未生成；rc.2 实际也没有安装成功（包仍是 0.1.7-rc.1）。另有旁证：C:\Users\16336\profiles\web\node_modules\@deepseek-ai（少拼了 .dsh 一层）在 02:33:24 被创建。

---

DSH (@deepseek-ai/dsh / DeepSeek Harness) — Loss of all sessions and state data (bug report)

• Reported: 2026-09-26 (local time UTC+8)
• Reporter: machine owner (C:\Users\16336)
• Product: @deepseek-ai/dsh (npm global install) + Windows desktop launcher
• Versions involved: installed package 0.1.7-rc.1 (install dir dated 2026-09-24 20:56); upgrade target of that day: 0.1.7-rc.2
• Environment: Windows 11; DSH_HOME=C:\Users\16336\.dsh; DSH_PROFILE=web; launched as dsh web

1. Summary

Between 02:32 and 02:36 (local) on 2026-09-26 the directories
profiles/, sessions/, storages/, dsh-usage/, task-board/ under $DSH_HOME
were re-initialized. All previous conversations (sessions), plugin state, the workspace
list, the usage ledger and settings were lost. Only one conversation created that day remains.

User's own description (translated):

"Last time I asked for a DSH upgrade, but in reality it looks like DSH was wiped —
all conversations, history, plugins were wiped."

The only surviving store is memory/memory.db (251 MB, created 2026-08-26).

2. Evidence (all of it reproducible)

2.1 Directory CreationTime — on Windows only a delete-then-recreate refreshes it

C:\Users\16336\.dsh                      C=2026-08-14 22:46:45   W=2026-09-26 11:17:47   <- long-lived dir
C:\Users\16336\.dsh\memory               C=2026-08-26 20:58:36   <- SURVIVED
C:\Users\16336\.dsh\memory\memory.db     C=2026-08-26 20:58:36   W=2026-09-26 02:36:27   (251,224,064 bytes)
C:\Users\16336\.dsh\task-board           C=2026-09-26 02:32:06   <- RECREATED
C:\Users\16336\.dsh\profiles             C=2026-09-26 02:36:31   <- RECREATED
C:\Users\16336\.dsh\profiles\web         C=2026-09-26 02:36:31
C:\Users\16336\.dsh\.anonymous-user-id   C=2026-09-26 02:36:47   <- RECREATED
C:\Users\16336\.dsh\sessions             C=2026-09-26 02:36:51   <- RECREATED

Reproduce:

foreach ($p in @("$env:USERPROFILE\.dsh","$env:USERPROFILE\.dsh\memory","$env:USERPROFILE\.dsh\memory\memory.db",
                 "$env:USERPROFILE\.dsh\sessions","$env:USERPROFILE\.dsh\profiles","$env:USERPROFILE\.dsh\storages")) {
  $i = Get-Item -Force $p; "{0}`tC={1}`tW={2}" -f $p, $i.CreationTime, $i.LastWriteTime }

Note: memory.db's C=2026-08-26 proves it was not copied in today — measured on this machine,
a Windows copy refreshes the destination's CreationTime and preserves LastWriteTime
(probe script included in the attached evidence package as 03-creationtime-copy-probe.txt).

2.2 The state stores contain only what was created that day

storages\workspace.json holds exactly one workspace:

"005917ee-4f0f-4ce7-b740-e5fede21de2c": {
  "path": "C:\\Users\\16336\\OneDrive\\<Documents>\\deepseek-harness\\<default workspace>",
  "title": "<default workspace>",
  "sessionIds": ["session-dc5721ff-d436-44ac-ba1b-262e06bd2b69"],
  "createdAt": "2026-09-25T18:36:51.668Z",     // == 2026-09-26 02:36:51 local
  "updatedAt": "2026-09-25T18:36:51.747Z"
}

sessions\ contains exactly one file: …/session-dc5721ff-…/session.v4.jsonl.zstd (created 02:36:51).
task-board\scheduler-v2.json is 28 bytes; dsh-usage\usage-ledger.json is 14 KB with no history.

2.3 Contradicts the upgrade helper's own stated risk assessment

C:\Users\16336\dsh-upgrade-to-017rc2.ps1 (created 2026-09-26 02:26, ten minutes before the loss)
states multiple times that this upgrade is safe for data:

• line 341: Info 'session data: skipped by design (V3->V4 restore is non-destructive)'
• lines 14–21: settings.yaml is ALREADY migrated … the irreversible rename CANNOT fire again. This upgrade has no settings risk.

Actual result: sessions/, storages/, dsh-usage/, task-board/, profiles/ were all
re-initialized, and $DSH_HOME now contains neither settings.yaml nor settings.yaml.imported.

2.4 The script's own backup and log directories do not exist

• line 325: backup dir should be C:\Users\16336\.dsh\dsh-backup-<ver>-<stamp> → missing
• line 407: log dir should be C:\Users\16336\.dsh\dsh-upgrade-logs\run-<stamp> → missing

So the loss is not the outcome of the helper running its normal backup → install → verify path;
whatever did it is on the upgrade/restart path where nothing was logged.

2.5 The upgrade itself never landed

%APPDATA%\npm\node_modules\@deepseek-ai\dsh\package.json  ->  "version": "0.1.7-rc.1"  (dir dated 2026-09-24 20:56)
Currently running process (started 2026-09-26 11:16:15):
  "C:\nvm4w\nodejs\node.exe" ...\npm/node_modules/@deepseek-ai/dsh/lib/bin.js web

→ rc.2 was never installed, yet the state re-initialization already happened.

2.6 Corroborating trace: an install/upgrade path using a wrong profile root

C:\Users\16336\profiles\web\node_modules\@deepseek-ai\ (empty dir tree) was created at
2026-09-26 02:33:24.

The profile root should be C:\Users\16336\.dsh\profiles\web; the directory that appeared is
C:\Users\16336\profiles\web — the .dsh segment is missing. A path-assembly problem on the
install/upgrade path was therefore active at exactly the time the state was re-initialized.

2.7 Recovery channels ruled out

• Recycle Bin: 0 items (deletion did not go through the Recycle Bin → permanent)
• Full-disk search (C:, D:): no second copy of session.v4.jsonl*, no dsh-backup-*, no dsh-upgrade-logs
• No other .dsh copy exists anywhere on disk

3. Timeline (2026-09-26, local UTC+8)

Time	Event
02:26	dsh-upgrade-to-017rc2.ps1 created (rc.1 → rc.2 upgrade helper)
02:30–02:41	several dot-dirs under the user profile written (.codex/.cua-driver/.local/.workbuddy/.android/.config)
02:32:06	.dsh\task-board recreated
02:33:24	C:\Users\16336\profiles\web\node_modules\@deepseek-ai created (wrong path)
02:36:27	memory.db written (not lost)
02:36:31	.dsh\profiles recreated
02:36:47	.dsh\.anonymous-user-id recreated
02:36:51	.dsh\sessions recreated + workspace.json written (the only surviving conversation starts here)
11:16:15	user restarts DSH (still rc.1)
11:17:47	.credentials.yaml recreated (re-login)

4. Questions / requests for the DSH team

1. Does the upgrade path touch $DSH_HOME's session and state directories? Specifically: in the
   rc.1 → rc.2 chain, is there any "if a state store is missing, silently create an empty one" logic,
   and what exactly triggers it?
2. Actual behaviour of the V3 → V4 session restore: on failure, does it delete or re-initialize the
   sessions/ root? Is the failure site preserved (quarantine / .bak)? The helper script asserts the
   path is "non-destructive", yet data disappeared — please point to the real code path.
3. The upgrade helper backs up only the install tree + profile config and explicitly skips session
   data (line 341). Please include session data in the official upgrade flow, or take an atomic
   rename backup (sessions.bak-<version>-<ts>) before any migration; no failure should end in deletion.
4. Profile path assembly bug: why was C:\Users\<user>\profiles\web\node_modules\@deepseek-ai
   created (missing .dsh)? Could the same mis-assembled path have written to — or deleted from —
   somewhere else?
5. Please add a dsh doctor --data (or equivalent) that prints the effective DSH_HOME, every storage
   root, and an existence/timestamp check, so users can self-diagnose after such an incident.

5. Preserved evidence (not cleaned up)

• C:\Users\16336\.dsh\ (incl. the only surviving store memory\memory.db)
• C:\Users\16336\profiles\ (the stray wrong-path tree created 02:33)
• C:\Users\16336\dsh-upgrade-to-017rc2.ps1 (created 02:26)
• C:\Users\16336\dsh-upgrade-scratch\ (upgrade scaffolding from 9-22)
• C:\Users\16336\AppData\Roaming\npm\node_modules\@deepseek-ai\{dsh, dsh.bak-0.1.7-alpha.1-20260922-224246, dsh-root}
• PowerShell history with all previous DSH upgrade/rollback commands:
  C:\Users\16336\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

[xiaoyuyu6420]

bug 报告本身无可挑剔。但先说更急的事：你的旧会话大概率还没死，恢复窗口每过一小时都在变小——趁现在 C 盘写入还少，按这个顺序做：

1. 立刻降低写入：暂停在这台机器上的下载/编译/大文件操作，也尽量别反复启动 dsh（每次启动都在往 C 盘写）。NTFS 的「重建」如果是删除+新建，旧 *.jsonl.zstd 的数据扇区多半还没被覆盖——这是可以恢复的。

2. 定向恢复：跑 Windows File Recovery（winfr，微软官方）或 Recuva，目标路径定向到 C:\Users\16336\.dsh\sessions，签名模式抓 *.jsonl.zstd。你的 USN journal 可用——恢复工具能列出 02:32–02:36 窗口内被删文件的精确清单，直接和你 gist 里的时间戳比对，一个不多一个不少。

3. 查「错误 HOME」假说（你的旁证很关键）：C:\Users\16336\profiles\web\node_modules\... 少拼了 .dsh 一层——这提示助手脚本当时可能把 C:\Users\16336 当成了 DSH_HOME 在操作。去 C:\Users\16336\ 根目录看有没有 02:33 前后新建的 sessions\、storages\、profiles\、dsh-backup-*、dsh-upgrade-logs\。如果助手在错误的树上做了「重建」，真实的 .dsh 可能根本没被碰（或者数据被挪去了那里）——这比文件恢复还省事。

4. memory.db 幸存是个好信号：它说明那次「重建」不是全目录 rm，而是选择性的——被删的文件在文件系统层面走的是正常删除路径，恰好是恢复工具最擅长的场景。

恢复之后，报告里「助手自己声明 skipped by design 但 dsh-backup-* 备份目录从未生成」这条建议单独强调——这是发布管线的直接证据，比「数据丢了」更需要维护者回应。也建议把 gist 挂进 #6520 的未修复清单。

（我做备份插件的，这种 rc→rc 升级正是最该先拍快照的场景——说多了都是泪，先把上面的恢复做了。）