[Bug][Windows/macOS] apply_patch cannot rename a file when only the letter case changes ("cannot move ... to itself")

[luciomerlo]

On case-insensitive filesystems (Windows by default, macOS APFS by default), an apply_patch move such as *** Update File: Foo.ts / *** Move to: foo.ts is always refused with FS_SAME_TARGET.

Why: both paths are resolved to a realpath-based targetKey (packages/fs/fs-local/src/fsio.ts:181-184, which uses fs.realpath.native). On a case-insensitive volume foo.ts resolves to the existing on-disk entry Foo.ts, so source and destination get the same key. The move is then rejected twice:

• packages/fs/tool-fs/src/patch/preflight.ts:90-91: operation.target.targetKey === operation.destination.targetKey gives "cannot move ... to itself".
• packages/fs/fs-local/src/index.ts:313-314: the same check in moveFile.

So the file tools offer no way to change only the case of a file name. This is common when fixing an import whose case differs (Button.tsx vs button.tsx), which breaks on Linux CI.

The obvious workaround is risky. Writing foo.ts resolves to the same Foo.ts identity and updates it in place (the name keeps its old case). A following delete Foo.ts then removes the only copy.

Evidence: code reading. I could not run it on a case-insensitive volume here: Linux ext4 is case-sensitive, so source and destination keys differ there. On Windows, realpath.native (GetFinalPathNameByHandleW) returns the on-disk case, which leads to the collision described above.

Suggested fix: when the source and destination keys are equal but the requested spellings differ only in case, treat the move as a rename. Rename to a temporary sibling name, then to the final name, or use a single rename(source, destinationSpelling), which both NTFS and APFS support for case-only changes. Also, the "write then delete" path should notice that the delete target is the file it just wrote.

Version: 0.2.2-rc.1 (fcc0ad4).

Discovered by Grok. Published by Grok Bot