@deepseek-ai/dsh-atomic-write profile写锁残留导致dsh plugin卡满120秒后失败

[IamAbler]

@deepseek-ai/dsh-atomic-write：锁文件在进程异常退出后不会被释放

@deepseek-ai/dsh-atomic-write@0.1.7-rc.1，packages/util/atomic-write。

withFileLock() 把 PID 写进 <file>.lock，但从来不读它。持锁进程被 kill -9 或崩溃、没走成 finally，锁文件就永久留下了。

之后每个写入方都要等满 waitMs 才失败。dsh plugin 那边是 120 秒（@deepseek-ai/dsh-plugin-manager 的 lockWaitMs，默认 12e4），所以现象就是"卡住不动，两分钟后报错"。跟 dsh web 开不开无关，重启也没用，只能手动删文件。

# 等价状态，不必真去杀进程；999999 需确保本机不存在（kill -0 999999 → No such process）
printf '999999\n' > "${DSH_HOME:-$HOME/.dsh}/profiles/web/package.json.lock"
dsh plugin --profile web install          # 等 120s 后报 writer lock 超时
rm "${DSH_HOME:-$HOME/.dsh}/profiles/web/package.json.lock"   # 立刻恢复

代码证据（lib/index.js:123-150，行号对应 0.1.7-rc.1 的发布产物；为可读性折行，逻辑未改，Windows EPERM 分支已省略）：

async function withFileLock(filename, operation, options) {
	const lockPath = `${filename}.lock`;
	const deadline = Date.now() + (options?.waitMs ?? DEFAULT_LOCK_WAIT_MS);
	for (;;) {
		try {
			await writeFile(lockPath, `${process.pid}\n`, {
				mode: 384, flag: "wx"
			});                                    // ← PID 写进去了
			break;
		} catch (error) {
			if (!await isLockContention(error, lockPath)) {
				// …Windows EPERM 分支…
			}                                      // ← 只判"文件存不存在"，不看内容
		}
		if (Date.now() >= deadline) throw new Error(
			`atomic-write: timed out waiting for the writer lock at ${lockPath}`);
		                                           // ← 等到点直接抛，不做恢复
		await new Promise((resolve) => setTimeout(resolve, delay));
		delay = Math.min(delay * 2, LOCK_RETRY_MAX_MS);
	}
	try {
		return await operation();
	} finally {
		await rm(lockPath, { force: true });       // ← 只有优雅退出才执行到这里
	}
}

isLockContention() 内部也只有一次 lstat(lockPath)（第 83 行），同样是判存在。整个文件 152 行里没有一次 readFile —— 更直接的是，这个模块从 node:fs/promises 只导入了 lstat, mkdir, rename, rm, writeFile，根本没引入任何读取函数。写进去的 PID 没有任何读取点。

源码注释把这件事写成了设计决定：

The contender never removes an existing lock because file age cannot prove that its owner stopped; orphan recovery is an operator action.

前半句成立：文件年龄确实证明不了持有者已死。后半句不成立：PID 能证明，而 PID 就写在文件里、只是从来没被读回。把"人工删文件"定为唯一恢复路径的代价是——一次异常退出就让后续每一次 profile 写入白等 120 秒，且跨重启存活。

建议争用时读一下那个 PID，process.kill(pid, 0) 返回 ESRCH 就当持有者已死，删掉锁重试；EPERM 以及任何读不出、不确定的情况一律按"活着"处理，避免在 Windows 上误删活锁。