# Objective

`FakeFs::rename` deletes files in two cases where `RealFs` leaves them
alone. Tests written against the fake see a file vanish where the real
filesystem keeps it, so the behavior cannot be tested at all and
anything relying on it drifts unnoticed.

There is already a test for the first case for `RealFs`,
`test_realfs_rename_ignore_if_exists_leaves_source_and_target_unchanged`,
but the fake had no counterpart.

## Solution

Return early in both cases instead of falling through to the removal.

For `ignoreIfExists` onto an existing target, `RealFs` reports success
and does not move anything. The fake kept the target but removed the
source. The fix also stops recording a move that never happened, which
would otherwise leave an open file handle pointing at the wrong path.

For a rename onto itself with `overwrite`, POSIX requires success with
no action. The fake assigned the entry onto itself and then removed it.
I found this while fixing the first one, and included it.

## Testing

I extended an existing test, and added two new ones. Each fails on
`main` and passes here.

I found this issue while working on #5369, where an LSP rename can send
`ignoreIfExists` and the fake made the resulting bug impossible to write
a test for.

Ran the tests only on macOS as the area seems platform agnostic, but
please let me know if I need to run them across all platforms.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

---

Release Notes:

- N/A