{"version":"2.1.282","anchor":"in-place-writes-can-refuse-hard-linked-files-mostly-dark","canonical_anchor":"in-place-writes-can-refuse-hard-linked-files-mostly-dark","heading":"In-place file writes can refuse hard-linked files, live on one path only","tier":"notice","area":"Elsewhere","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/in-place-writes-can-refuse-hard-linked-files-mostly-dark","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### In-place file writes can refuse hard-linked files, live on one path only\n\nClaude Code can now refuse to rewrite a hard-linked file in place, but the general switch is off and only one write path uses it\n\n**Unclear.** Which of Claude Code's file-editing actions uses the path where the refusal is active is not settled.\n\n**What**\n\nA hard link is a second name on disk for the same file, so changing the file under one name changes it under every name. When Claude Code cannot save a file the usual safe way, it falls back to rewriting the file in place. Before this release that fallback wrote the file whatever its number of names. Now:\n\n- The in-place fallbacks (in both the normal and background file writers, and in the other in-place writers) check how many names the file has.\n\n- If it has more than one, the write is refused with an `EMLINK` error and a new `HardLinkWriteRefusedError`. The message begins \"Could not rewrite ... in place: this file has other names on disk (it is hard-linked\", explains that changing it would alter the file under every name, and asks you to remove the extra links.\n\n- The general switch for this check is always off in this build. The only place it is live is one write that passes `refuseHardLinkedInPlace` explicitly.\n\n**Why**\n\nWhere it applies, an edit can no longer quietly change the other copies of a hard-linked file. Everywhere else, in-place writes behave as before for now.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}