-i replaces the originals. The write is atomic, so an interruption cannot corrupt anything — but replacing a file has three consequences, and they are easier to accept before the run than after.
All three follow from replacing the file rather than editing it. Extended attributes are lost — Finder tags, Spotlight comments and quarantine flags live on the inode, and the rename installs a new one. Hard links are broken, so other links to the old inode keep the unscrubbed content. The mtime is reset, deliberately, because it is metadata too. If any of those matter, use -d instead and move the results into place yourself.
Same as always: scrubpony -n -r ~/Pictures writes nothing and shows you the scale of what is about to change.
The scrubbed copy is built in a temporary beside each file, fsynced, and renamed over the top in one indivisible step. Kill the process at any moment and the file on disk is either exactly what it was or exactly what it should become — never a partial of either.
$ scrubpony -i -r ~/Pictures ~/Pictures/2026/IMG_4471.jpg: removed 3 segments, 4944 bytes (49.2%), orientation preserved scrubpony: 834 scrubbed, 366 already clean, 3 not JPEG, 4 skipped, 2 failed scrubpony: 257 carried GPS coordinates
A file that would not change is not touched at all — same inode, same mtime. That is decided by comparing the bytes, not by counting segments: a photo scrubbed once still carries our own orientation block, so a second pass drops one segment and writes an identical one back. Only the bytes settle it. Permissions and ownership are carried onto every replacement, so a file that was 0600 does not come back world-readable.
scrubpony --check -r ~/Pictures exits 0.ls -l..scrubbed.jpg files appeared: -i replaces rather than adding.Yes. tests/run_interrupt.sh asserts exactly this by SIGKILLing a 24 MB in-place scrub thirty times at varying moments and checking that nothing but the two legal states ever appears — and that no stray temporary is left behind.
No, and there is no flag for it. The mtime is metadata: a scrubbed file still carrying its original capture time defeats part of the purpose.
No — they ask for opposite things and the combination is a usage error, exit code 64.
Not necessarily. The rename guarantees no observer sees a half-written file; it does not guarantee the old blocks are unrecoverable. On a copy-on-write filesystem, an SSD with wear levelling, or anywhere with snapshots or Time Machine, the pre-scrub content may persist.
Strips identifying metadata out of JPEGs without touching a pixel. C99, no dependencies beyond libc, macOS and Linux, MIT-licensed.