write tool cannot create new files on exFAT volumes (Windows): EISDIR from hard-link no-replace publication

[llrllr0123]

Summary

On Windows, the write tool fails to create a new file when the workspace sits on an exFAT volume (e.g. an external USB drive). Overwriting an already-read file with write (or editing with edit) works fine. No configuration/workaround exists on the DSH side.

Environment

• Windows 11 x64
• dsh 0.1.2-alpha.2 (commit 0a53fb5)
• workspace on an exFAT external drive (E:, Western Digital My Passport); NTFS volumes work fine

Symptom

cannot write "E:\egg_seg\dsh_rw_test.txt": EISDIR: illegal operation on a directory, link 'E:\egg_seg\.dsh_rw_test.txt.5520.<uuid>.tmpdir\dsh_rw_test.txt.tmp' -> 'E:\egg_seg\dsh_rw_test.txt'

Reproduced in the workspace root and in every subdirectory (.tmp, etc.). It is not a sandbox/permission issue: pwsh-level writes (e.g. Set-Content) succeed on the same paths. The failure is deterministic and happens for any new file.

Root cause

writeFileAtomic in packages/fs/fs-local/src/fsio.ts publishes new files through the createIfAbsent branch, which uses a hard link as its no-replace primitive:

if (createIfAbsent !== undefined) {
  try {
    await linkFile(tempPath, absolutePath)
  } catch (error: unknown) {
    await throwGuardedCreateFailure(error, absolutePath, createIfAbsent.displayPath, inspectPublicationTarget)
  }
}

exFAT does not support hard links, so CreateHardLinkW fails; libuv maps that failure to EISDIR, and the error is treated as a plain IO error instead of (or in addition to) the intended "target exists" case. Replacement writes (edit / overwrite of an observed file) take the Windows ReplaceFileW path on win32, which exFAT does support — hence only create-new-file is affected.

Relevant lines: packages/fs/fs-local/src/fsio.ts (writeFileAtomic, around lines 533-614); no-replace semantics also covered by packages/fs/fs-local/tests/filesystem.spec.ts (createIfAbsent tests).

Suggested fix

When link fails with a "filesystem does not support hard links" class of error (EISDIR / EPERM / ENOTSUP), fall back to a publication that preserves no-replace without hard links, e.g.:

1. lstat the destination to confirm it is still absent, then rename the staged file into place — accepts a small TOCTOU window (a concurrent creator race becomes last-writer-wins instead of a rejection on such filesystems).
2. Or stage as today, then open the final path with wx (CREATE_NEW) and copy/fsync the staged content — native exclusive-create, no hard links, but not strictly atomic.
3. Optional optimization: probe once per volume (try link on a probe file) and remember unsupported volumes for the session.

A fix should keep the existing createIfAbsent tests green on NTFS (hard-link path unchanged there), and ideally add an exFAT/reparse test if feasible on CI.

Happy to provide a patch if a maintainer confirms the direction.

[llrllr0123]

Duplicate of #3884 — my earlier report for the same bug (exFAT/FAT32 + network mounts, EISDIR error mapping, TOCTOU trade-off, working ~40-line patch). This second thread was created unintentionally and is now closed; #3884 is the authoritative report.