atomic-write 的 writer lock 在 Windows 上遇到「PID 存在但不可探测（EPERM）」时无法自愈，插件管理会卡 2 分钟

[LQR03]

现象

DSH Desktop 0.2.1-rc.2（dsh --version → 0.2.1-rc.2），Windows 11 x64，profile desktop。

在插件市场里更新插件（尤其是更新市场自己）之后，~/.dsh/profiles/desktop/package.json.lock 会残留。此后在 设置 → 插件 里停用/启用任何插件都要先等约 2 分钟，然后：

停用失败: atomic-write: timed out waiting for the writer lock at
C:\Users\21989\.dsh\profiles\desktop\package.json.lock

删除这个 lock 文件才恢复。更新本身是成功的（package.json 里版本已经是新的）。

现场

• 锁内容 34080（单个 PID + 换行），mtime 14:53:45 就是获取时刻，之后几分钟不再变化。
• package.json mtime 14:53:46（写入成功，比锁晚 1 秒）。
• node -e "process.kill(34080,0)" → EPERM；对照组（不存在的 PID）→ ESRCH。
• 更早一把同名锁内容 2908，同一天第二次出现。
• 插件管理器 change() 传入 waitMs: 120000（@deepseek-ai/dsh-plugin-manager/lib/index.js:2400，默认值在 :1576）。
• 市场侧同场景已上报：[Bug][Windows] 更新插件市场后 profile 残留 package.json.lock，之后启用/停用任何插件都要等 2 分钟然后失败 dsh-market/dsh-market#914。

源码里的判断链（@deepseek-ai/dsh-atomic-write/lib/index.js）

• withFileLock 只在 holderExited(record) 为真时调用 takeOverExitedLock；
• holderExited 要求 process.kill(pid, 0) 抛出 ESRCH；
• EPERM 被当成「持锁者仍存在」（可能是别的用户或受保护进程）→ 继续等待 → 到期抛错；
• 注释也写明：“A holder whose PID a live process reused keeps its lock until an operator removes it.”，没有心跳、过期或强制接管。

问题在于 Windows 上「进程存在但当前用户探测被拒」与「PID 被复用 / 受保护进程」都表现为 EPERM，二者无法区分；而 dsh plugin 子进程被 taskkill /F 之后留下的锁正好落进这个分支——没有人工介入就永远恢复不了。

复现步骤

1. DSH Desktop 0.2.1-rc.2，profile desktop。
2. 在插件市场里更新插件（尤其市场自身）。
3. 设置 → 插件 → 停用任意插件。
4. 等约 2 分钟后报 atomic-write: timed out waiting for the writer lock。
5. 删除 %USERPROFILE%\.dsh\profiles\desktop\package.json.lock 后立即恢复。

建议

1. 锁记录里加上 boot id / 进程启动时间（GetProcessTimes 或 /proc/<pid> 的启动时刻），把接管判断从「kill(pid, 0) 的信号结果」改成「启动时间不匹配 → 视为死锁」。
2. 或者给锁加心跳 mtime，超过阈值未更新即可接管。
3. 至少在超时错误里给出锁路径与可执行的恢复步骤（现在文案只说 timed out）。
4. 为 dsh plugin 这类长操作提供「清理自己创建的锁」的入口，避免子进程被强杀后 finally 无法执行。

[PerryLink]

这条链我按 rc.2 源码逐行对过，你写的判断全部成立，而且比报告里说的更死一点。

packages/util/atomic-write/src/index.ts：

• :112-125 holderExited(record) 里，process.kill(pid, 0) 捕获后只认一种码：:125 return code === 'ESRCH'。:124 的注释就写着「EPERM 表示进程以另一个用户身份存在」——所以 EPERM 一律按「持锁者还活着」处理。
• :150-152 takeOverExitedLock 第一句就是 if (record === undefined || !holderExited(record)) return false，所以 EPERM 连接管资格都没有。
• :259 只有接管成功才 continue，否则一路走到 :262 抛 atomic-write: timed out waiting for the writer lock at <path>。

所以你的现场是自洽的：锁里那个 PID 已经被别人复用了，探测得到 EPERM，代码按「活着」处理，等满 waitMs 再报超时。:227 那句注释「A holder whose PID a live process reused keeps its lock until an operator removes it」说的就是这件事 —— 它是写明的设计，不是漏判。

那真正的缺口在哪？不在判据，在报错什么都不告诉你。:262 那条消息只有路径，没有 PID、没有探测得到的 errno、没有锁文件年龄。运维看到「timed out waiting for the writer lock at …\package.json.lock」只能去翻文件内容才知道该删谁。要补的三样都在手边：

1. 超时消息里补上 record 里的 PID、探测结果（ESRCH/EPERM/其他）、以及锁的 mtime 年龄；
2. 年龄超过某个阈值时，在消息里说明「若确认无 writer，可删除该锁文件」——EPERM 与「PID 被复用」在这台机器上确实无法区分，但可以把判断权交回人；
3. 别做基于年龄的自动接管。真在跑的长写入（大 profile 打包）也会长时间不更新锁，自动接管会变成两个 writer 同时写 package.json，代价比多删一次文件大得多。

如果要做显式清理入口，takeOverExitedLock 里已经有一套「先写 .takeover-<hash> 认领文件、再复核 record 未变」的机制（:153-174），强制路径可以复用它的认领语义，只是把 holderExited 这个前置换成「操作者显式确认」——这样至少不会在无人时自己动。

最后一句：waitMs: 120000 是调用方传的，锁层本身没有默认等待时长的问题；两分钟这个体感来自插件管理器的 change()，不是 atomic-write。