dsh-hardlink-publish-fallback

LIMITATIONS

Known limitations

- **Only repairs new-file creation.** Updates and `edit` never used the hard-link path, so they are already fine and are not intercepted. - **Windows-oriented symptom, host-agnostic logic.** The plugin keys on the failure signature, not on the platform, so it also covers any POSIX filesystem that refuses `link()` with the same shape. - **Does not help when writing to a drive root.** A separate, cross-filesystem defect makes `writeFileAtomic` call `mkdir(<root>, { recursive: true })`, which returns `EPERM` on Windows drive roots (verified here on both an NTFS and an exFAT volume). Because this plugin completes the write through the same service, a new file written directly at a drive root still fails. Use a subdirectory. - **Not a substitute for an upstream fix.** This is a runtime workaround for a defect in `dsh-fs-local`'s publication logic; see [DEFECT-REPORT.md](./DEFECT-REPORT.md) for the full analysis and a proposed fix. - **A small, inherited TOCTOU window.** The absence re-check and the write are separate calls. This is the same window the original `writeText` already has between its own probe and its publication; the no-clobber guard is what the re-check preserves, and a racing creator still cannot be silently overwritten beyond that window.