One copy plan that both the CLI and the browser render #20

Merged

wokoman merged 1 commit from feat/copy-plan into main

2026-08-28 20:23:43 +02:00

wokoman commented

2026-08-28 20:23:35 +02:00

Owner

One answer to "what will this copy do", produced by the copy module and rendered by whoever asked — the command line checks it, the browser turns it into a confirmation.

Both callers needed the same four facts before a copy starts: which files were found, how many need converting, whether ffmpeg is available, and whether the copy should be refused outright. Neither asked for them; each assembled them by hand from three separate helpers, and the predictable happened — the browser's version came out missing the refusal, which was #6.

The plan and the dry run stay two things. The ticket left that open, so here is the reasoning. They answer different questions from different inputs: a plan is about the batch and is deliberately computable without a Database, which is the whole point — it is what lets a copy be refused before the device is opened. The dry run is about each individual file and needs the database to know what is already there. Merging them would mean opening the device before the refusal could fire, undoing #6. The dry run is untouched.

The walker moves into the copy module with them, since the plan is now its only caller. #10 deliberately left it in cli.rs for this ticket to place, rather than moving it twice. Its tests move with it.

Progress reporting is one callback taking a Step — scanning, or reading tags — rather than two separate loops each with their own callback. Both steps are slow for the same reason and neither is predictable: the walk is IO-bound, and deciding what needs converting opens every .m4a, since ALAC and AAC share a container. The browser matches on the step to redraw every eighth file; the command line ignores it.

One behaviour change worth naming: the command line used to short-circuit its "does anything need converting" check with any, and now gets a full count from the plan. On a batch of .m4a files that is more work, since each one has to be opened to tell ALAC from AAC. It buys the single answer both front ends share, and the count is what the browser's confirmation has always needed.

The plan is asserted with no device attached — a directory of an MP3, a FLAC and a JPEG plans as two files, one converting, the image excluded, with the refusal following whether ffmpeg is actually present and the tag-reading step reported with the right total.

Verified on the real device end to end: dry run, then copying two throwaway tracks, listing them, removing them, and confirming the track count returned to 6307 with nothing left behind. iTunesDB, iTunesDB.ext and SysInfo were backed up first. The itdb_splr_validate warnings in the output are the known pre-existing smart-playlist quirk on this device, recorded in SPEC.md.

68 unit tests pass, cargo clippy --all-targets clean.

Closes #8.

One answer to "what will this copy do", produced by the copy module and rendered by whoever asked — the command line checks it, the browser turns it into a confirmation. Both callers needed the same four facts before a copy starts: which files were found, how many need converting, whether ffmpeg is available, and whether the copy should be refused outright. Neither asked for them; each assembled them by hand from three separate helpers, and the predictable happened — the browser's version came out missing the refusal, which was #6. **The plan and the dry run stay two things.** The ticket left that open, so here is the reasoning. They answer different questions from different inputs: a plan is about the batch and is deliberately computable *without* a `Database`, which is the whole point — it is what lets a copy be refused before the device is opened. The dry run is about each individual file and needs the database to know what is already there. Merging them would mean opening the device before the refusal could fire, undoing #6. The dry run is untouched. The walker moves into the copy module with them, since the plan is now its only caller. #10 deliberately left it in `cli.rs` for this ticket to place, rather than moving it twice. Its tests move with it. Progress reporting is one callback taking a `Step` — scanning, or reading tags — rather than two separate loops each with their own callback. Both steps are slow for the same reason and neither is predictable: the walk is IO-bound, and deciding what needs converting opens every `.m4a`, since ALAC and AAC share a container. The browser matches on the step to redraw every eighth file; the command line ignores it. One behaviour change worth naming: the command line used to short-circuit its "does anything need converting" check with `any`, and now gets a full count from the plan. On a batch of `.m4a` files that is more work, since each one has to be opened to tell ALAC from AAC. It buys the single answer both front ends share, and the count is what the browser's confirmation has always needed. The plan is asserted with no device attached — a directory of an MP3, a FLAC and a JPEG plans as two files, one converting, the image excluded, with the refusal following whether ffmpeg is actually present and the tag-reading step reported with the right total. Verified on the real device end to end: dry run, then copying two throwaway tracks, listing them, removing them, and confirming the track count returned to 6307 with nothing left behind. `iTunesDB`, `iTunesDB.ext` and `SysInfo` were backed up first. The `itdb_splr_validate` warnings in the output are the known pre-existing smart-playlist quirk on this device, recorded in `SPEC.md`. 68 unit tests pass, `cargo clippy --all-targets` clean. Closes #8.

wokoman added 1 commit

2026-08-28 20:23:35 +02:00

feat(copy): one plan that both front ends render 542b615239

Both callers needed the same four facts before a copy and each assembled
them by hand from three helpers; the browser's version came out missing
the refusal, which was #6. The walker moves in with them, since the plan
is the only thing that calls it.

Closes #8.

wokoman merged commit 4a5a74cd3e into main

2026-08-28 20:23:43 +02:00

wokoman deleted branch feat/copy-plan

2026-08-28 20:23:43 +02:00

wokoman referenced this pull request from a commit

2026-08-28 20:23:44 +02:00

Merge pull request #20: one copy plan that both the CLI and the browser render