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

New issue

Open

opened 2026-08-25 22:29:24 +02:00 by wokoman · 0 comments

wokoman commented

2026-08-25 22:29:24 +02:00

(Migrated from code.nolog.cz)

What to build

When a copy finishes with failures, both the command line and the browser can say which files failed and why — not just how many.

Today the browser reports "5 failed" and nothing more. The information exists at the moment each file fails, and is then thrown away: the per-file callback receives the outcome borrowed, so no caller can keep an error even if it wants to. The browser does not try; it counts the failure and drops the reason. For a copy of several hundred files off a network share, "5 failed" is not an answer anyone can act on.

The counting rules have the same problem in a quieter way. Both callers rebuild the same accumulator by hand — copied, duplicates, untitled, failed — and both restate the same rule about when to suggest installing ffmpeg. Two hand-built copies of one set of rules is how they drift.

The fix is to let the copy module return the summary it already computes, instead of making each caller reconstruct it from a stream of events. The progress callback stays, but narrows to what genuinely needs to be a callback: telling the caller where the run has got to so it can repaint.

Acceptance criteria

A batch copy returns a summary owning the counts and the failed files with their reasons
The browser's copy result can name the files that failed and why, rather than only counting them
The command line's output is unchanged
Neither caller assembles counts by hand any more
The rule about when to suggest installing ffmpeg lives in one place
The summary can be asserted in a test with no device attached
cargo clippy --all-targets clean; full suite passes

Notes

Surfacing failures in the browser needs somewhere to put them. The existing message viewer — the popup behind w that shows what libgpod complained about — is the obvious home, and reusing it is preferable to inventing a second list. Confirm before building anything new for this.

Blocked by

#3 — the summary needs to be assertable without a device, which is the point of the fixture.

## What to build When a copy finishes with failures, both the command line and the browser can say **which** files failed and why — not just how many. Today the browser reports "5 failed" and nothing more. The information exists at the moment each file fails, and is then thrown away: the per-file callback receives the outcome *borrowed*, so no caller can keep an error even if it wants to. The browser does not try; it counts the failure and drops the reason. For a copy of several hundred files off a network share, "5 failed" is not an answer anyone can act on. The counting rules have the same problem in a quieter way. Both callers rebuild the same accumulator by hand — copied, duplicates, untitled, failed — and both restate the same rule about when to suggest installing ffmpeg. Two hand-built copies of one set of rules is how they drift. The fix is to let the copy module return the summary it already computes, instead of making each caller reconstruct it from a stream of events. The progress callback stays, but narrows to what genuinely needs to be a callback: telling the caller where the run has got to so it can repaint. ## Acceptance criteria - [ ] A batch copy returns a summary owning the counts and the failed files with their reasons - [ ] The browser's copy result can name the files that failed and why, rather than only counting them - [ ] The command line's output is unchanged - [ ] Neither caller assembles counts by hand any more - [ ] The rule about when to suggest installing ffmpeg lives in one place - [ ] The summary can be asserted in a test with no device attached - [ ] `cargo clippy --all-targets` clean; full suite passes ## Notes Surfacing failures in the browser needs somewhere to put them. The existing message viewer — the popup behind `w` that shows what libgpod complained about — is the obvious home, and reusing it is preferable to inventing a second list. Confirm before building anything new for this. ## Blocked by - #3 — the summary needs to be assertable without a device, which is the point of the fixture.