fix: report renames honestly in a dry run

--dry-run described a FAT32 rename as an encode. process() skipped the rename whenever dry_run was set, then found no file at the target and fell through to the encode path, so a preview of enabling --fat32-safe announced a full re-encode of every track whose name held a reserved character. The real run moves those files in a moment. A preview that inverts the cost of the thing being previewed is worse than no preview at all. Prune compounded it. With nothing renamed, the pre-sanitisation files are still on disk, and they were reported as orphans due for deletion -- so the same dry run claimed the library would be re-encoded and the originals thrown away, neither of which is true. Renames are now their own outcome: reported as "would rename" in a dry run, counted separately from encodes in the pass summary, and excluded from the orphan list when a dry run leaves them in place.
2026-08-25 11:34:42 +01:00
parent 1b0097f910
commit 3f50577de6
3 changed files with 86 additions and 6 deletions
@@ -229,6 +229,13 @@ producing files that already exist byte for byte. The run moves them instead,
 and says so. Prune then finds nothing to remove because nothing was left
 behind.

+Renames are counted apart from encodes in the pass summary, and `--dry-run`
+reports `would rename` rather than `would encode` — the difference between the
+two is a minute against an afternoon, so a preview that conflated them would be
+worse than no preview. A dry run also does not list the pre-rename files as
+orphans: nothing was moved, so they are still there, but they are what a real
+run would move rather than what it would delete.
+
 ### Album art

 Rockbox looks for cover art **on the filesystem** — `cover.jpg`, `folder.jpg`