fix: report renames honestly in a dry run #7

2026-08-25T11:37:00+01:00

lyrathorpe commented

2026-08-25 11:37:00 +01:00

Problem

I told Lyra a dry run would name every rename. It does the opposite.

process() skipped the rename whenever dry_run was set, then found nothing
at the target and fell through to the encode path. So previewing --fat32-safe
announced a full re-encode of every track whose name held a reserved
character — when 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, so they were listed as orphans due for deletion. The same dry run
therefore claimed the library would be re-encoded and the originals thrown
away. Neither is true.

Change

A rename is now its own outcome:

--dry-run logs would rename A -> B, not would encode
renames are counted apart from encodes in the pass summary, so 0 encoded, 1247 renamed reads correctly
a dry run 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, not what
it would delete

Testing

69 tests, green locally and in docker build --target test. Four new: the dry
run reporting a rename, not calling the old paths orphans, moving nothing, and
the separate counts in the summary.

## Problem I told Lyra a dry run would name every rename. It does the opposite. `process()` skipped the rename whenever `dry_run` was set, then found nothing at the target and fell through to the encode path. So previewing `--fat32-safe` announced **a full re-encode** of every track whose name held a reserved character — when 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, so they were listed as orphans due for deletion. The same dry run therefore claimed the library would be re-encoded *and* the originals thrown away. Neither is true. ## Change A rename is now its own outcome: - `--dry-run` logs `would rename A -> B`, not `would encode` - renames are counted apart from encodes in the pass summary, so `0 encoded, 1247 renamed` reads correctly - a dry run 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*, not what it would delete ## Testing 69 tests, green locally and in `docker build --target test`. Four new: the dry run reporting a rename, not calling the old paths orphans, moving nothing, and the separate counts in the summary.

lyrathorpe added 1 commit 2026-08-25 11:37:00 +01:00

fix: report renames honestly in a dry run

Build and publish container / build (pull_request) Successful in 1m38s

Details

3f50577de6

--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.

lyrathorpe merged commit d6233c2995 into main

2026-08-25 11:37:57 +01:00

lyrathorpe deleted branch fix/dry-run-renames

2026-08-25 11:37:58 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lyrathorpe/music-mirror#7