fs writeFileAtomic: no-replace publish fails on exFAT/FAT32 (hard links unsupported)

[llrllr0123]

Summary

writeFileAtomic (packages/fs/fs-local/src/fsio.ts) publishes staged files with the no-replace primitive link() when createIfAbsent semantics are requested. On filesystems that do not support hard links — exFAT/FAT32 and some network mounts — this primitive is unsupported, so every no-replace write to such volumes fails, even when the target is absent.

Reproduction

• Windows 11; DSH built from source (master @ 0.1.1-rc.2)
• Workspace on a 4 TB exFAT external drive (NTFS system volume: unaffected)
• Any fs write with createIfAbsent to that volume → guarded-create failure (FS_NOT_FOUND), even the first write to a fresh path

Root cause

• link(2) is only implemented on NTFS/APFS/ext-family. On Windows the underlying CreateHardLink fails and libuv maps the error to EISDIR (ERROR_DIRECTORY), which is misleading — neither operand is a directory. On Linux/macOS the equivalent failure surfaces as ENOTSUP/EOPNOTSUPP/ENOSYS.
• Node does not fall back: hard links are the only way to get atomic no-replace publish in writeFileAtomic.

Proposed fix

Keep the guarded-create path where supported. When link() fails with one of EISDIR/EPERM/ENOTSUP/EOPNOTSUPP/ENOSYS/EXDEV and the publication target does not exist (lstat → ENOENT/ENOTDIR), fall back to rename() (check-then-publish). If the target exists, report FS_NOT_OBSERVED exactly as today.

Trade-off (accepted on purpose): on exFAT the guarantee degrades from “atomic no-replace” to “check-then-publish”, which has a small TOCTOU window between the check and the rename — but then the rename itself is still atomic, and a concurrent creator can only lose in the narrow window. exFAT offers no better primitive: open(O_EXCL) would create the target but leave it partially visible to readers, and copyFile(COPYFILE_EXCL) is likewise non-atomic for readers.

A working patch (~40 lines, single file) is available and has been running on my exFAT workspace. I can share the full diff or open a PR if external pull requests are accepted (per CONTRIBUTING.md they currently are not).

Questions for the team: is check-then-publish acceptable, or would you prefer a different primitive/approach for no-replace writes on exFAT-class volumes?

[398894496-arch]

Same hard-link publish, different volume: macOS smbfs (company share mounted as smbfs), stock @deepseek-ai/dsh@0.1.1-rc.2.

New-session persist in dsh-session-persistence-jsonl does fs.link(tmp, final). smbfs returns ENOTSUP. The desk dies on “new session” even though same-volume rename works. After a successful publish, fsync on the directory can also ENOTSUP; swallowing that avoids a second crash.

This is the same class as exFAT link() here and in #4981 (EISDIR on Windows). Fallback link → rename on ENOTSUP / EXDEV / EISDIR would cover both.

No PR (CONTRIBUTING). Workaround: https://github.com/398894496-arch/TDHarness-coding mark company-session-smbfs-rename-v1.

macOS 把工作区/会话放在 smbfs 上时，fs.link 发新会话会 ENOTSUP；rename 可以过。