Measurements on the exFAT hard-link publication failure

[Mushroomcowisheggs]

exFAT volume: hard-link publication fails, rename fallback verified

write cannot create a new file on a volume whose filesystem has no hard links —
exFAT, FAT32, some network shares — while updating an existing file and edit
continue to work. The defect and its root cause are covered in #3884 and #5704
(EISDIR originates in Node/libuv; upstream: nodejs/node#65817).

This is what a fixed (non-removable) exFAT volume actually does.

OS	Windows 11 (10.0.26100.0)
Node	v22.20.0
dsh	0.1.5-rc.1
@deepseek-ai/dsh-fs-local	0.1.5-rc.2
Volume	a volume formatted exFAT, fixed rather than removable

The failure tracks the filesystem, not whether the drive is a USB device.

The failure

cannot write "<workspace>\<file>": EISDIR: illegal operation on a directory,
  link '<workspace>\.<file>.<pid>.<uuid>.tmpdir\<file>.tmp' -> '<workspace>\<file>'

Deterministic for every new file, in the workspace root and in subdirectories
alike. Overwriting an existing file reports Updated file, and edit succeeds.

The primitives

With the staged temp file already written, against the same target path, in one run:

fs.linkSync(temp, target)     // → code=EISDIR  errno=-4068  syscall=link
fs.renameSync(temp, target)   // → OK, content reads back correctly

mkdir of the staging directory, open(tempPath, 'wx'), writeFile, chmod and
sync all succeed in the same run. fs.renameSync equally succeeds into a
subdirectory that had to be created first.

Falling back to rename

Attempting the link, and degrading to rename only while the target is still
absent, behaves as intended on this volume — one case per row:

Case	Result
New file, target absent	falls back to rename; file published; content correct
Concurrent creator, target already present	no fallback; the original failure is raised and the existing content survives byte-for-byte
Staging file after a successful fallback	consumed by the publication; no residue

The collision path is deliberately outside the fallback: EEXIST is not a
hard-link-unsupported signal, so a genuine race still reports contention rather
than overwriting.

NTFS

On an NTFS volume the same call succeeds and the two paths share an inode — a
real hard link, not a copy. The existing create-if-absent publication therefore
behaves as before on NTFS, and the fallback never engages there.

Drive roots fail independently of the filesystem

writeFileAtomic begins with mkdir(dirname(target), { recursive: true }). On
Windows a drive root already exists, but mkdir reports it as EPERM, and
recursive: true tolerates only EEXIST:

fs.mkdirSync(driveRoot, { recursive: true })  // → code=EPERM  syscall=mkdir  (exFAT root)
fs.mkdirSync(driveRoot, { recursive: true })  // → code=EPERM  syscall=mkdir  (NTFS root)

Not a hard-link problem and not exFAT-specific — it reproduces on both filesystems,
so it blocks writing a new file directly at a drive root on any Windows volume. It
also propagates into any workaround that completes the write through the same
service, because that mkdir runs there too.

Other capabilities of the volume

fs.symlinkSync also fails with EISDIR. A DSH_HOME placed on such a volume
cannot boot: dsh-app-boot's healProfilesModuleFallback symlinks the install into
the profile during composition.

[wannagoxuf]

2026-10-19 复核：桌面版 44.7.0 仍然没有修；并附一个已在真实安装上跑通的热补丁

English TL;DR — Re-verified against master @ 687f282e8625c6b8d11ff58211a90524be2e4317 (2026-10-17T07:22:43Z, the commit behind Desktop 44.7.0): packages/fs/fs-local/src/fsio.ts:633-638 still publishes a newly-created file with a bare link() and no fallback. The shipped dsh/node_modules/@deepseek-ai/dsh-fs-local/lib/index.js is byte-identical between Desktop 44.0.0 and 44.7.0 (41 311 bytes, sha256 63fbb41d2c33e07111884b798be507e68c2752acab8249c821c20ade436e894f) → the defect survives both releases, and every automatic update silently wipes any local mitigation (we hit exactly that: the 44.0.0 workaround was erased by the 44.7.0 update 11 days later).

1. 用户为什么普遍误判成"中文路径坏了"

失败信息里的路径多半带中文（工作区在移动硬盘/共享盘上），但纯 ASCII 路径同样失败，一字不差：

Error: cannot write "E:\work\tmp\repro_link.js":
EISDIR: illegal operation on a directory,
link 'E:\work\tmp\.repro_link.js.<pid>.<uuid>.tmpdir\repro_link.js.tmp' -> 'E:\work\tmp\repro_link.js'

不需要 Harness 也能复现（同一台机器，两个卷各一次）：

node -e "const fs=require('fs');const d=process.argv[1];fs.mkdirSync(d+'/.t.tmpdir',{recursive:true});fs.writeFileSync(d+'/.t.tmpdir/t.tmp','x');try{fs.linkSync(d+'/.t.tmpdir/t.tmp',d+'/t');console.log('LINK OK')}catch(e){console.log('LINK',e.code,e.errno,e.syscall)}" 'E:\work\tmp'
# exFAT -> LINK EISDIR -4068 link      |  C:\...(NTFS) -> LINK OK

EISDIR (errno -4068) 是 libuv 对 CreateHardLinkW 在不支持硬链接的卷上的失败翻译。用户看到 "illegal operation on a directory" 只会去怀疑目录、编码、中文名——方向完全错。fsio.ts:551-552 的注释其实已经写明"Link errno values vary by platform and filesystem… missing hard-link support"，但代码只做了错误分类，没有做发布回退。

2. 已在生产安装上验证可用的最小补丁（就地、字节等长、可回滚）

在硬链接失败且错误码表明该卷不支持硬链接时，退到独占创建（同样是不覆盖已有文件的 no-replace 语义）：

if (createIfAbsent !== undefined) {
  try {
    await linkFile(tempPath, absolutePath)
  } catch (error) {
    if (isHardLinkUnavailable(error)) {
      try {
        const publishHandle = await open(absolutePath, 'wx', 0o600)
        try {
          await publishHandle.writeFile(content, { encoding: 'utf8', ...signal ? { signal } : {} })
          await publishHandle.sync()
        } finally { await publishHandle.close() }
      } catch (fallbackError) {
        await throwGuardedCreateFailure(fallbackError, absolutePath, createIfAbsent.displayPath, inspectPublicationTarget)
      }
    } else {
      await throwGuardedCreateFailure(error, absolutePath, createIfAbsent.displayPath, inspectPublicationTarget)
    }
  }
}

function isHardLinkUnavailable(error: unknown): boolean {
  return ['EISDIR', 'EPERM', 'ENOSYS', 'ENOTSUP', 'EOPNOTSUPP'].includes((error as NodeJS.ErrnoException)?.code)
}

自检结果（把补丁后的字节从已安装的 app.asar 里重新读出来加载，不是从工作副本）：

用例	结果
在 exFAT + 多层中文目录下创建新文件	✔ 成功，无 .tmpdir 残留
中文 + 含空格文件名、中文内容	✔ 成功
未读取就覆盖已存在文件	✔ 仍被拒 FS_NOT_OBSERVED，原文件未被改动
NTFS 卷上的新建	✔ 仍走硬链接，行为不变
模拟"无硬链接卷"（注入抛 EISDIR 的 internals.linkFile）	✔ 回退成功

补充两点给官方：Electron 的 asarIntegrity fuse 在这两版都是 DISABLED（exe 内 fuse 串后状态 101100011），所以这类就地缓解技术上可行；但缓解只在新 host 进程启动后生效——桌面版 host 是主进程的子进程，打完补丁必须完全退出并重启程序（这一条我们踩了两次）。

3. 建议直接用你们仓库里已有的先例，而不是新发明

packages/session/session-persistence-jsonl/src/win32.ts:134-138 已经有 Windows 上跨卷可用的 no-replace 原语：

export async function publishNewFileWin32(existing: string, replacement: string): Promise<void> {
  const api = await win32()
  const ok = api.moveFileExW(toNamespacedPath(existing), toNamespacedPath(replacement), MOVEFILE_WRITE_THROUGH)
  if (ok === 0) throw win32Error('MoveFileExW', api.getLastError(), existing, replacement)
}

MoveFileExW 不带 MOVEFILE_REPLACE_EXISTING 时天然拒绝覆盖，且不依赖硬链接——fs-local 的 createIfAbsent 分支正好需要这个语义。

另外同型缺陷还在 packages/attachment/attachment-local/src/store.ts:283 与 :359：那里的 link() 只把 EEXIST 当成可恢复错误（注释写 "Private same-filesystem directories make EEXIST the only recoverable link race"——前提正是"同文件系统即支持硬链接"），讨论区已有人报 ATTACHMENT_WRITE_FAILED。

最后，建议在 Host 启动时对当前工作卷做一次能力探测并明确提示（我在全仓库里找不到任何 GetVolumeInformationW / 文件系统类型判断——所有 NTFS 假设都是隐含的）。

---

本帖只做一件事：给出**"44.7.0 仍未修"的版本状态 + 已在真实安装上验证的补丁**。缺陷本身与 #3884 / #4981 / #5127 / #5704 / #7774 相同，不再另开新帖。

[Mushroomcowisheggs]

之前发了个插件
https://github.com/Mushroomcowisheggs/dsh-hardlink-publish-fallback
在我电脑上测试是没问题的。装上之后会自动探测这种失败并绕过，可以暂时解决write失败问题。
当然，更好的方式还是从源头上先判断文件系统再分别使用对应处理。