### System details

AMD Ryzen 7 5800X3D, NVIDIA RTX 3080, Omarchy 4.0.4 (imv 5.0.1, imagemagick 7.1.2.31)

### What's wrong?

Omarchy's imv config binds Ctrl+R to rewrite the file on disk (added in #3312):

```
<Ctrl+r> = exec mogrify -rotate 90 "$imv_current_file"
```

I pressed it on a portrait photo straight from my camera (7008×4672 JPEG, 7 MB). imv stopped responding, and afterwards the JPEG was a 98,304-byte file that no longer decodes ("Premature end of JPEG file").

What I could pin down:

- **imv blocks while the command runs.** imv runs `exec` binds through `system()` (`command_exec` in `src/imv.c`), which explains it not responding while mogrify is running.
- **Interrupting mogrify reproduces the damage.** Killing mogrify partway through its ~0.9 s run on a copy of another photo from the same camera left an undecodable JPEG with the same byte count, 98,304.
- **Whether a backup is left depends on the folder.** The photo's folder was read-only (`dr-x------`), but the JPEG itself was writable (`-rw-------`). In my writable-folder tests, interrupted runs left the untouched original as a `~` backup. In the read-only-folder test, the JPEG was corrupted and nothing was left.

Reproduction on a disposable copy (timing varies; the kill has to land during the write):

```
d=$(mktemp -d) && cp some-photo.jpg "$d/p.jpg" && chmod 600 "$d/p.jpg" && chmod 500 "$d"
mogrify -rotate 90 "$d/p.jpg" & pid=$!
sleep 0.5; kill -9 "$pid"; wait "$pid"
ls -l "$d"                 # only p.jpg, a fraction of its original size
magick identify "$d/p.jpg" # Premature end of JPEG file
```

I couldn't find what interrupted mogrify on my machine (nothing in the journal, no core dump, no OOM). Still, Ctrl+R rewrites the original without any on-screen warning, and the test above shows that an interrupted run can leave an unreadable JPEG with no backup.

(Investigated with help from Claude Code.)