桌面版 0.2.1-rc.2：profile 根目录不可达时静默退出（ENOENT mkdir .dsh\profiles\desktop）

[Lirghtbyte]

环境

• @deepseek-ai/dsh-desktop 0.2.1-rc.2（nightly），Electron 44.7.0 / Node 24.21.0，win32 x64
• Windows 10 Pro 22H2（19045.6466），Intel i5-9400F / 16 GiB
• 安装路径：G:\deepseek；DSH_HOME = %USERPROFILE%.dsh
  （G:\deepseek.dsh 是指向该目录的目录联接）

现象
启动桌面版后没有窗口，进程直接退出，无任何错误提示。

关键日志

Error: ENOENT: no such file or directory, mkdir 'C:\Users\<user>\.dsh\profiles\desktop'
    at mkdirSync (node:fs:1410:26)
    at DesktopProjectManager.withLock (app.asar/lib/main.js:3600:3)
    at DesktopProjectManager.applyRelease (app.asar/lib/main.js:3592:14)
    at app.asar/lib/main.js:12314:32

当天 12 条崩溃记录，其中 11 条堆栈完全一致：

• 12:13:52 / 12:13:55 / 12:13:57（把 .dsh 改名备份之后）
• 20:44:57 – 20:45:17 共 8 次（卸载重装、清理数据目录期间）
  另有 1 条 11:05:10 的 Desktop renderer exited: launch-failed。

复现步骤

1. 安装并启动一次后退出
2. 把 %USERPROFILE%.dsh 改名为 .dsh.bak
3. 启动 DeepSeek Harness.exe → 进程立即退出，并在 %APPDATA%@deepseek-ai\dsh-desktop\logs\ 写入上述 ENOENT 日志
4. 目录改回原名 → 恢复正常

期望行为
withLock 在启动最早期就 mkdir(profile)。DSH_HOME 不可达（目录被移走 / junction 目标失效）时，建议：

• 启动前校验 DSH_HOME（realpath + reparse point 状态），失败则回退默认目录并提示；
• 复用已有的 "DeepSeek Harness is unavailable" 恢复界面，给出可操作选项，而不是静默退出；
• 崩溃日志补充 raw path / realpath / reparse point 信息，便于定位迁移问题。

附带发现

1. 与 dsh web 互斥时的提示不足（startupAddressInUse），实际很难判断是端口占用还是目录问题。
2. profile 写锁残留会永久阻塞插件安装：lock 文件记录 PID，此处 PID 11252 恰好是一个存活的 DSH 进程，之后所有写入 package.json 的操作都 atomic-write: timed out waiting for the writer lock。建议锁记录 PID + 进程启动时间 + token，或提供 --force-unlock。

附件
12 份原始崩溃日志（crash-logs/）随帖附上。
active__crash-2026-10-22T12-45-06-112Z-host.log
active__crash-2026-10-22T12-45-02-303Z-host.log
active__crash-2026-10-22T12-45-03-684Z-host.log
active__crash-2026-10-22T12-45-07-960Z-host.log
active__crash-2026-10-22T12-45-09-636Z-host.log
active__crash-2026-10-22T12-45-12-158Z-host.log
active__crash-2026-10-22T12-45-17-064Z-host.log
bak1149__crash-2026-10-22T03-05-10-237Z-renderer.log
bak1701__crash-2026-10-22T04-13-52-063Z-host.log
bak1701__crash-2026-10-22T04-13-55-823Z-host.log
bak1701__crash-2026-10-22T04-13-57-873Z-host.log
active__crash-2026-10-22T12-44-56-997Z-host.log

[PerryLink]

这 12 条崩溃是同一行抛的，而且和你自己的复现步骤是同一个因果链。

apps/desktop/src/project-manager.ts:93，withLock 的第一件事：

mkdirSync(this.paths.profile, { recursive: true, mode: 0o700 })

它前面没有任何 try，所以这一步失败会直接抛给启动流程（applyRelease → withLock），窗口都来不及开。

你的复现步骤正好制造了它：G:\deepseek\.dsh 是指向 %USERPROFILE%\.dsh 的目录联接，而你把 .dsh 改名备份之后，这个联接就悬空了。recursive: true 的 mkdir 穿过悬空联接时，报的是叶子路径的 ENOENT——也就是日志里那条 C:\Users\<user>\.dsh\profiles\desktop，而不是"联接断了"。

所以顺序是：先恢复数据，再谈启动。

1. 把备份目录改回 %USERPROFILE%\.dsh（或重建联接指向它）。
2. 确认 G:\deepseek\.dsh 能列出内容（悬空联接列不出来）。
3. 再启动。

如果你本来就不需要这个联接，删掉它、把备份改回原位更省事——多一层联接只会多一个失败点。

只读了源码（22ddee3），没有在 Windows 上复现。