Copy reports which files failed, not just how many #19

Merged

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

2026-08-28 20:19:33 +02:00

wokoman commented

2026-08-28 20:19:25 +02:00

Owner

When a copy finishes with failures, both front ends can now say which files failed and why, not just how many.

The information existed at the moment each file failed and was then thrown away: the per-file callback received the outcome borrowed, so no caller could keep an error even if it wanted to. The browser did not try — it counted the failure and dropped the reason. For a copy of several hundred files off a network share, "5 failed" is not an answer anyone can act on.

copy_all now returns the summary it was already computing — copied, duplicates, untitled, and each failed file with its reason — and hands the running summary to the progress callback, so the callback stays for what genuinely needs to be a callback: telling the caller where the run has got to so it can repaint. Neither front end assembles counts by hand any more, including the dry run, which folds its outcomes into the same type through the same rules. The rule about when to suggest installing ffmpeg lives on the summary, so the two places that used to restate it now ask it.

Command-line output is unchanged. In the browser, a copy that had failures opens the popup listing each file and its reason — reusing the viewer behind w rather than inventing a second list, as the ticket asked.

The summary is asserted with no device attached: a batch of three — one file, the same file again, and a .mp3 that is not an MP3 — comes back as one copied, one duplicate, one failed, with the failure naming the right file and carrying a non-empty reason, and the callback observed to see the run advance 1, 2, 3.

Also fixes a race I introduced in #15. The three batch-removal tests each built their audio files at fixed temp paths and deleted them when done, so running in parallel one test could delete a file another was still copying — it surfaced as copy into the fixture: stat …/ironpod-<pid>-batch-first.mp3. It was behind the intermittent failure I flagged in #17 and could not reproduce at the time. Temp audio files now get a unique suffix per call, not per name. Measured: two failures in twenty runs before, none in twenty after.

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

Closes #7.

When a copy finishes with failures, both front ends can now say **which** files failed and why, not just how many. The information existed at the moment each file failed and was then thrown away: the per-file callback received the outcome *borrowed*, so no caller could keep an error even if it wanted to. The browser did not try — it counted the failure and dropped the reason. For a copy of several hundred files off a network share, "5 failed" is not an answer anyone can act on. `copy_all` now returns the summary it was already computing — copied, duplicates, untitled, and each failed file with its reason — and hands the running summary to the progress callback, so the callback stays for what genuinely needs to be a callback: telling the caller where the run has got to so it can repaint. Neither front end assembles counts by hand any more, including the dry run, which folds its outcomes into the same type through the same rules. The rule about when to suggest installing ffmpeg lives on the summary, so the two places that used to restate it now ask it. Command-line output is unchanged. In the browser, a copy that had failures opens the popup listing each file and its reason — reusing the viewer behind `w` rather than inventing a second list, as the ticket asked. The summary is asserted with no device attached: a batch of three — one file, the same file again, and a `.mp3` that is not an MP3 — comes back as one copied, one duplicate, one failed, with the failure naming the right file and carrying a non-empty reason, and the callback observed to see the run advance 1, 2, 3. **Also fixes a race I introduced in #15.** The three batch-removal tests each built their audio files at fixed temp paths and deleted them when done, so running in parallel one test could delete a file another was still copying — it surfaced as `copy into the fixture: stat …/ironpod-<pid>-batch-first.mp3`. It was behind the intermittent failure I flagged in #17 and could not reproduce at the time. Temp audio files now get a unique suffix per call, not per name. Measured: two failures in twenty runs before, none in twenty after. 67 unit tests pass, `cargo clippy --all-targets` clean. Closes #7.

wokoman added 1 commit

2026-08-28 20:19:26 +02:00

feat(copy): return the summary instead of making callers rebuild it f1fdb5b047

The browser reported "5 failed" and dropped every reason, because the
per-file callback handed outcomes over borrowed. Both front ends also
rebuilt the same four counts by hand, which is how they drift.

Also fixes a race the batch-removal tests introduced: three of them built
their audio files at the same temp paths and deleted them when done, so in
parallel one test deleted a file another was still copying. Two failures
in twenty runs before, none in twenty after.

Closes #7.

wokoman merged commit 251fadcdbb into main

2026-08-28 20:19:33 +02:00

wokoman deleted branch feat/copy-summary

2026-08-28 20:19:33 +02:00

wokoman referenced this pull request from a commit

2026-08-28 20:19:34 +02:00

Merge pull request #19: copy reports which files failed, not just how many