[Critical] Windows：卸载 link: 安装的插件会跟随 junction 递归删除，掏空插件源码仓库

[lovezi0]

• 严重级别：Critical — 不可逆的用户数据丢失（源码仓库）
• 类型：Bug（数据丢失）+ 安全边界缺陷
• 影响平台：Windows（junction 语义）。macOS/Linux 上 pnpm 使用符号链接、lstat 能正确识别，推测不受影响，请官方确认
• 影响功能：Desktop 插件页 Remove，以及 dsh plugin --profile <p> remove —— 在**本地目录安装（link: / 绝对路径）**这一常规开发工作流上触发

---

1. 一句话摘要

在 Windows 上以 link:（本地目录）方式安装的插件，其在 profile/node_modules/<pkg> 处是 junction。执行卸载时，删除逻辑把 junction 当作普通目录递归进入它的目标目录（也就是开发者的源码仓库根），从仓库根开始按目录项顺序逐条删除。本次事故中，插件 dsh-model-extension 的源码仓库被删掉了 .deepseek-harness/（agent 长期记忆全部丢失）与 .git 的头部文件（HEAD、config、index、logs、info、hooks、description、branches、COMMIT_EDITMSG），仓库直接报 fatal: not a git repository。删除恰好在遍历到 .git/objects 之前中断，其余工作树内容幸免 —— 这是运气，不是设计。

---

2. 环境

项	值
OS	Windows_NT 10.0.26300 x64
Node（删除逻辑运行时）	v24.18.1（宿主 checkout 侧 v24.18.0）
DSH 版本	宿主源码 checkout = dsh-v0.2.1-alpha.4（commit 86a402200d）；
dsh web	版本：0.2.1-alpha.4
dsh desktop windows	版本：0.2.0-rc.2
Profile	desktop（Electron 应用内插件页）与 web 两侧装有同一插件
安装方式	pnpm link:：desktop/package.json、web/package.json 与两侧 pnpm-lock.yaml 均记录 link:<repo>/dsh-model-extension，lockfile 解析为 version: link:<repo>/dsh-model-extension
触发操作	在插件页对该插件执行 Remove（见 §4.1 的调用链）

---

3. 现场证据

3.1 link 形态（事故后仍在，可直接核验）

$DSH_HOME\profiles\desktop\node_modules\dsh-model-extension  [JUNCTION] -> <repo>\dsh-model-extension
$DSH_HOME\profiles\web\node_modules\dsh-model-extension      [JUNCTION] -> <repo>\dsh-model-extension

注意：链接本身还在，目标却已被掏空了一半。这与「删除器在删链接内容的阶段就异常退出、从未走到 unlink 链接」一致。

3.2 时间线（本地时间 = UTC+8，取自 NTFS 时间戳）

时刻	事件	证据
09:24:24	web profile 一次插件操作	profiles/web/.plugin-manager/logs/operation-w306W0；pnpm-lock.yaml mtime 09:24:27
09:26:07	web/package.json 重写	mtime
09:42:03	源仓库 .git 最后一次条目增删（删除器正在 .git 内逐条删）	.git 目录 mtime（重建前实测值）
09:43:57	desktop profile 插件操作记录生成	profiles/desktop/.plugin-manager/logs/operation-5EHkrq（mtime = 2026-10-16T01:43:57Z）
09:43:58	desktop/node_modules 条目变动	目录 mtime
09:44:21	desktop/package.json + pnpm-lock.yaml 重写、.plugin-manager 更新	mtime

3.3 被删内容严格呈「目录项字母序 + 中途停止」形态

.git 内被删（全部字母序在 objects 之前）	.git 内幸存（objects 及之后）
branches、COMMIT_EDITMSG、config、description、HEAD、hooks、index、info、logs	objects、ORIG_HEAD、packed-refs、refs

仓库根同理：.deepseek-harness（字母序在 .git 之前）被整体删除；.github、assets、docs、lib、plans、scripts、src、upgrade plan、package.json 等排在 .git 之后，因中断而幸存。

objects 一个对象都没被删，用统计独立性排除「删了一部分」：

现存 loose 前缀目录 = 185 / 256，对象文件 = 322
322 个随机 SHA 覆盖 256 个前缀桶的期望值约 183 → 实测 185，属自然稀疏
缺失前缀样本 = 02,08,09,0e,15,16,17,1a,1d,1e,26,2c（随机分布；00/01 仍在，说明并非按前缀顺序删）
master=e8fb6606 与 v1.0.0 的对象均在；git fsck 仅 2 个 dangling commit，无 missing 对象

---

4. 根因分析

4.1 卸载链路自身不做删除

packages/boot/plugin-manager/src/index.ts:686-717 的 removeBundle() 只做 runPnpm([ + remove + , name, …])（见该文件 711 行），删除动作交给 pnpm 子进程完成。插件管理层这一层没有任何「链接目标不可触碰」的守卫。

4.2 仓库里唯一的 junction 防呆，恰好在关键判定上失效

apps/desktop/src/owned-directory.ts 的注释已经明确承认这个风险：

// Electron 的 recursive rm 会顺着嵌套的 Windows junction 进入已安装资源（原文注释）

它为此手写了 removeOwnedDirectory()。但该函数对根路径的判定用的是 lstatSync：

const stat = lstatSync(path, { throwIfNoEntry: false })
if (stat === undefined) return
if (stat.isSymbolicLink()) { unlinkSync(path); return }   // ← junction 走不到这一支
if (!stat.isDirectory()) throw new Error(...)
for (const entry of readdirSync(path, { withFileTypes: true })) {
  const child = join(path, entry.name)
  if (entry.isDirectory()) removeOwnedDirectory(child)    // 子项遍历用 Dirent，这一层是对的
  else unlinkSync(child)
}
rmdirSync(path)

在 Windows 上，Node v24 的 lstat() 不会把 junction 识别为符号链接。 我在本机同一 Node 运行时上实测（临时目录里创建 junction 后立刻探测）：

探测方式	isSymbolicLink()	isDirectory()
fs.lstatSync(junction)	false	true
fs.statSync(junction)	false	true
fs.readdirSync(parent, { withFileTypes: true }) 得到的 Dirent	true	false

于是对 removeOwnedDirectory(<node_modules>/<link 包名>) 而言：根级 lstat 判定「这是个普通目录」→ 保护短路 → readdirSync(path) 穿过 junction 读到的是源仓库根的内容 → 进入逐条递归删除。函数自己的注释说要防的那件事，被它自己踩中了。

矛盾点非常集中：同一个 junction，Dirent 认得、lstat 认不得。该函数遍历子项时用了正确的 Dirent 语义，只在根路径上用错了 lstat —— 这不是「作者没想到」，而是一个可以一行修掉的判定错误。

4.3 这层防呆本来也覆盖不到卸载路径

grep -rn removeOwnedDirectory 显示调用方只有：apps/desktop/scripts/test-host-updates.ts、test-workspace-updates.ts、tests/owned-directory.spec.ts、tests/fixtures/owned-directory-smoke.mjs —— 全部是 Desktop 更新自测脚本与测试夹具。插件卸载路径没有使用它，也没有任何等价保护。因此即使 §4.2 被修好，link: 插件的卸载仍然没有防线。

4.4 事故为什么「只删了一半」

删除按目录项顺序推进，在 .git 中删完 logs 之后、处理 objects 时终止。可能原因无法从记录中确证（见 §6.1）：或首个 unlinkSync 遭遇 EPERM（对象文件被 git 进程 / 索引器 / 杀软占用）抛错冒泡中止，或 pnpm 子进程被超时/取消终止（github-connection.ts 的注释表明 DSH 会 terminate its descendants）。无论哪一种，用户数据能否保住取决于删除何时失败。

---

5. 复现步骤

5.1 最小语义复现（不需要安装 DSH，直接验证 §4.2 的判定缺陷）

const fs = require("node:fs")
fs.mkdir("D:/tmp/jprobe/t/.git", { recursive: true })
fs.writeFileSync("D:/tmp/jprobe/t/.git/HEAD", "ref")
fs.symlinkSync("D:/tmp/jprobe/t", "D:/tmp/jprobe/link", "junction")
const st = fs.lstatSync("D:/tmp/jprobe/link")
console.log(st.isSymbolicLink(), st.isDirectory())   // Windows 实测: false true  → owned-directory.ts 的保护短路
const de = fs.readdirSync("D:/tmp/jprobe", { withFileTypes: true }).find(e => e.name === "link")
console.log(de.isSymbolicLink(), de.isDirectory())   // 实测: true false          → 同一对象，Dirent 判定正确

5.2 端到端复现（请在隔离目录进行，切勿指向真实仓库）

# 1) 造一个假的「插件源码仓库」，放入可观察的敏感文件
$src  = "D:\tmp\jprobe\fake-plugin"
$prof = "D:\tmp\jprobe\profile"
New-Item -ItemType Directory -Force -Path "$src\.git", "$src\mem", "$src\src" | Out-Null
Set-Content -Path "$src\package.json" -Value (ConvertTo-Json @{ name = "fake-plugin"; version = "0.0.1"; type = "module"; main = "index.js" })
Set-Content -Path "$src\.git\HEAD" -Value "ref: refs/heads/master"
Set-Content -Path "$src\mem\MEMORY.md" -Value "CANARY"

# 2) 用与 pnpm link: 同形的 junction 把它装进 profile
New-Item -ItemType Directory -Force -Path "$prof\node_modules" | Out-Null
cmd /c mklink /J "$prof\node_modules\fake-plugin" "$src"

# 3) 走 DSH 的卸载路径（CLI 等价；Desktop 侧请在插件页 Remove）
dsh --profile <p> plugin remove fake-plugin

# 4) 断言：只应移除链接本身，源目录内容必须完好
Get-ChildItem -Force $src          # 期望：.git/mem/src/package.json 仍在
Test-Path "$src\mem\MEMORY.md"    # 期望：True

---

6. 附带发现（同一次事故暴露的次要问题）

1. 文档缺风险告知：开发文档与插件管理页把「本地目录 / link 安装」作为常规开发流程推荐，但未提示在 Windows 上它会把开发仓库直接置于删除路径之下。

---

7. 期望行为与建议修复

期望：卸载 / 清理 link:（或 file:）安装的包时，只移除 profile 里的链接条目并回写 manifest 与 lockfile，绝不触碰链接目标的内容。

1. 修 removeOwnedDirectory() 的根级判定：与子项遍历统一改用 readdir 的 Dirent（或对根路径先取父目录 Dirent），使 junction / symlink 一律走 unlinkSync 分支、不进入目标。
2. 卸载路径复用同一个守卫：removeBundle() 在删除 node_modules/<name> 前先判定 reparse point，命中即只删链接。
3. 加一道「越界即停」的硬保险：删除前比较 realpath(link) 与 realpath(profile/node_modules)，若目标的真实路径不在 profile 内，拒绝递归删除并明确报错。
4. Desktop 插件页对 link: 安装的包给出显式标记，并在卸载二次确认里写明「仅移除链接，源目录保持不变」，让语义对用户可见。

本机实测可用于第 1/2 条的替代判据（供参考）：fs.readlinkSync(junction) 在部分受限环境下也会失败，因此不建议用 readlink 做探测；Dirent.isSymbolicLink() 是本次实测中唯一稳定正确的信号。

---

[argszero]

Source check against 86a402200d — two of your findings confirmed, one extended, and one I read the other way

Thank you for the evidence: the timeline, the alphabetical-order shape and the objects statistical test make this a report someone can act on. I traced the path on the current default branch. §4.1 and §4.3 hold; §4.2 is where I disagree, and the disagreement moves the fix.

1. §4.1 — confirmed, and the module is cleaner than you say

PluginManager.removeBundle() is at packages/boot/plugin-manager/src/index.ts:686; the package work is this.runPnpm(['remove', name, …]) at :711, and runPnpm (:754) spawns the child with cwd: this.profile.dir.

What I can add: the module performs no directory deletion at all. Its node:fs imports are existsSync/readFileSync (:3) and readFile/rm (:4); there is no rmSync, no rmdir and no readdir anywhere under packages/boot/plugin-manager/src, and the single rm (:803) deletes a profile file (manifest / lockfile / patch) that did not exist before, not a package directory. So the walk that emptied your repository ran inside the pnpm child process; no harness code opens profile/node_modules/<pkg> for writing.

2. §4.3 — confirmed

git grep removeOwnedDirectory returns exactly four callers: apps/desktop/scripts/test-host-updates.ts:53, apps/desktop/scripts/test-workspace-updates.ts:81, apps/desktop/tests/owned-directory.spec.ts and apps/desktop/tests/fixtures/owned-directory-smoke.mjs. All four are Desktop update self-tests. The removal path does not call it — as you say.

3. §4.2 — I read this the other way, and the falsifier is in this repository

You write that on Windows Node v24's lstat() does not report a junction as a symbolic link, so removeOwnedDirectory's root branch falls through into the recursive walk. apps/desktop/tests/owned-directory.spec.ts asserts the opposite, on Windows, with a root-level junction:

symlinkSync(target, link, process.platform === 'win32' ? 'junction' : 'dir')
removeOwnedDirectory(link)                                   // the junction IS the root path
expect(lstatSync(link, { throwIfNoEntry: false })).toBeUndefined()
expect(readFileSync(join(target, 'sentinel'), 'utf8')).toBe('preserved')

The link is made with fs.symlinkSync(…, 'junction') — the mechanism your §5.1 probe uses — and handed to the function as the root path. Both assertions hold only if lstatSync(path).isSymbolicLink() is true there. The same file's first test does it with a nested junction and asserts the target survives too.

So one of the two is wrong on Windows: those assertions, or the lstat row of your §5.1 table. It is worth settling before fixing, because fix (1) aims at a function your own §4.3 removes from the removal path — if the table is right the project also has a Windows-red test to explain, and if the assertions are right the function is already correct and the deletion came from somewhere else.

One line separates them, printing the mode rather than the two booleans:

const st = fs.lstatSync("D:/tmp/jprobe/link")
console.log(st.mode.toString(8), st.isSymbolicLink(), st.isDirectory())

A link reports 120000 (S_IFLNK); a directory reports 40000. I could not run your table myself — this machine is macOS and a junction is an NTFS reparse point — which is why I am asking rather than asserting.

4. The one command that decides the layer

By elimination the traversal is pnpm remove's, and the harness cannot guard inside it: removeBundle hands the child a directory and a name, and everything after that is pnpm's. No DSH involvement is needed to find out where the deletion happens:

mklink /J profile\node_modules\fake-plugin src
cd profile && pnpm remove fake-plugin

If src survives, the caller is implicated; if it is gutted the way your repository was, it is pnpm's removal of a link: dependency, and the report gets a much smaller subject. It is also worth checking whether the destroyed package was the one the profile's package.json recorded as link: at the moment of the removal — both of your profiles carried it.

5. Your fixes (2), (3) and (4) survive whichever way it lands

• (2) and (3) are the right shape, and can land where the decision is still ours — before the child runs: reject when realpath(link) leaves the profile, or unlink the reparse point and skip the recursion. (4) is documentation the plugin page can carry either way.
• The tree already refuses to follow junctions in three other places — apps/desktop/src/owned-directory.ts (root check and Dirent walk), packages/boot/app-boot/src/profile.ts removeLinkProjections/symlinksUnder ("symlinks or junctions"), and apps/desktop/packaging/README.md:108 ("Node removes the runner-owned source directory without following dependency junctions") — so the doctrine exists. This path is the one that delegates it to another program.
• On the plugin plane a guard is possible, but it is a mitigation and not the fix: the pluginManager service instance can be shadowed, so a plugin could refuse a removeBundle whose profile dependency is a link:/file: spec whose realpath leaves the profile, before the child runs. It cannot stop pnpm from following a junction the guard never saw, and it protects only profiles that have the guard installed. I am evaluating whether it is worth publishing; either way it does not replace the fix above.

[lovezi0]

我还发现了另外一个问题，link安装的插件在卸载时未移除node_modules下的link路径。

时间线

---

1. dsh插件项目，本地通过link方式安装到dsh desktop
2. desktop ui卸载插件 -> pnpm击穿源码仓库导致源码仓库文件被删除
3. 本地尝试恢复插件源码仓库 -> 源码仓库恢复成功
4. desktop ui - 插件 - 添加插件，通过npm包形式安装插件 -> 插件安装失败 -> pnpm又一次击穿源码仓库导致源码仓库文件被删除
5. 排查击穿原因发现 ...\profiles\desktop\node_modules\下还存在原来本地link的仓库？？？？？？？？？？？？？厚礼蟹！

---

[lovezi0]

世界线收束，最终该问题可能指向

1. dsh插件项目，本地通过link方式安装到dsh desktop
2. desktop ui卸载插件，但...\profiles\desktop\node_modules\下还存在原来本地link的仓库
3. desktop ui - 插件 - 添加插件，通过npm包形式安装插件 -> 插件安装失败 -> pnpm击穿源码仓库导致源码仓库文件被删除

[xiaoyuyu6420]

给插件作者一个可能的好消息：你的仓库大概率能完整救回。删除在遍历到 .git/objects 之前中断——而 git 的全部历史（所有提交、分支、blob）都存在 objects 里。丢掉的那些文件（HEAD/config/index/logs/hooks 等）全是可再生的脚手架：

1. 重建 HEAD（分支名不记得就先写 main，fsck 会帮你找回来）：

   echo ref: refs/heads/main > .git/HEAD
   

2. 重建最小 config（remote 地址你肯定知道）：

   [core]
     repositoryformatversion = 0
     bare = false
   [remote "origin"]
     url = https://github.com/<you>/<repo>.git
   

3. git reset（根据 HEAD 的 tree 重建 index）→ git status 应能看到完整工作树；
4. 有不确定的提交或分支：git fsck --lost-found 把 objects 里的悬空提交全列出来（reflog 丢失不影响 objects 的完整性）；
5. 验证：git log、git fsck 无错，工作树 diff 干净，即恢复完成。

给 lovezi0 和后续所有人的警示：你实测的「npm 形式重装又一次击穿」说明安装和卸载两条路径都踩这个洞——在官方修掉（对 junction/reparse point 做 lstat 识别、只删链接本身不递归进入）之前：

• 源码仓库先做一份冷备份（压缩包或 robocopy /MIR 到另一块盘）再动任何插件装卸操作；
• 恢复出来的仓库尽快 git push 一份到远端。

另外一个跨帖观察：这是本讨论区第二起「工具跟随链接/名字误伤真实数据」的事故（上一起是升级助手在错误的 HOME 上重建、#7921），共同点是删除/重建前没有验证目标身份。给官方的修复优先级建议里，这一条值得排在很前面——它不是边角，是「开发者日常操作一次就掏空源码仓库」的等级。