One progress reporter spans every path of a snapshot. Its counts of files and bytes processed run across all the paths, but each path's scan phase replaced the totals with that path's own, so a second path smaller than the first showed more than 100%.
Each path's scan phase now adds its files and size to the totals; SetTotalSize is renamed AddTotalSize because it now adds. It also restarts the rate behind the ETA when each path's scan phase ends: the rate is the bytes processed since then over the time since then, so a path's scan phase does not lower the rate while that path is processed.
New tests: two paths backed up with one scanner, the second smaller, checking the percentage and the file counts; and a path's scan phase not lowering the rate while that path is processed.
Judgement call: the totals cover the paths scanned so far, so the percentage drops when the next path's scan phase adds its totals, and the ETA covers only the paths already scanned.
Judgement call: during a later path's scan phase, the rate and ETA are still the previous path's, the rate falling as that scan goes on.
The issue says the ETA went negative; it was computed negative and printed as unknown.
Directories count toward the total size but produce no chunks, so the percentage ends just under 100%, as on a one-path snapshot; the test asserts at most 100%.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/271.
One progress reporter spans every path of a snapshot. Its counts of files and bytes processed run across all the paths, but each path's scan phase replaced the totals with that path's own, so a second path smaller than the first showed more than 100%.
Each path's scan phase now adds its files and size to the totals; `SetTotalSize` is renamed `AddTotalSize` because it now adds. It also restarts the rate behind the ETA when each path's scan phase ends: the rate is the bytes processed since then over the time since then, so a path's scan phase does not lower the rate while that path is processed.
New tests: two paths backed up with one scanner, the second smaller, checking the percentage and the file counts; and a path's scan phase not lowering the rate while that path is processed.
- Judgement call: the totals cover the paths scanned so far, so the percentage drops when the next path's scan phase adds its totals, and the ETA covers only the paths already scanned.
- Judgement call: during a later path's scan phase, the rate and ETA are still the previous path's, the rate falling as that scan goes on.
- The issue says the ETA went negative; it was computed negative and printed as `unknown`.
- Directories count toward the total size but produce no chunks, so the percentage ends just under 100%, as on a one-path snapshot; the test asserts at most 100%.
Model: opus-5-5
internal/snapshot/progress.go:155-161 (AddTotalSize): the processing start time is now set once, when the first path's scan phase ends. Every later path's scan phase (loading known files, walking the tree), when nothing is processed, therefore counts as processing time in the rate of the summary line and the detailed report. On a snapshot whose first path has nothing to back up, as in a usual incremental run, the second path's rate and ETA were right before this change and are now wrong: the rate is understated and the ETA overstated by about as long as that path's scan phase took. Acceptable: measure the rate over processing time only, for example from the bytes processed since the current path's processing started and the time since then, while the percentage and the remaining bytes keep using the totals across paths. Add a test that a later path's scan phase does not lower the rate.
Model: opus-5-5
1. `internal/snapshot/progress.go:155-161` (`AddTotalSize`): the processing start time is now set once, when the first path's scan phase ends. Every later path's scan phase (loading known files, walking the tree), when nothing is processed, therefore counts as processing time in the rate of the summary line and the detailed report. On a snapshot whose first path has nothing to back up, as in a usual incremental run, the second path's rate and ETA were right before this change and are now wrong: the rate is understated and the ETA overstated by about as long as that path's scan phase took. Acceptable: measure the rate over processing time only, for example from the bytes processed since the current path's processing started and the time since then, while the percentage and the remaining bytes keep using the totals across paths. Add a test that a later path's scan phase does not lower the rate.
Model: opus-5-5
AddTotalSize now restarts the rate for every path, recording the time and the bytes processed when that path's scan phase ends; the rate is the bytes processed since then over the time since then, while the percentage and the remaining bytes still use the totals across paths. Both reports take it from one helper, processRate, and TestProcessRateNotLoweredByLaterScanPhase checks the rate while a second path is processed after a 30-second scan phase. Left as is: during a later path's scan phase, the detailed report still shows the previous path's rate, falling as that scan goes on.
Model: opus-5-5
1. `AddTotalSize` now restarts the rate for every path, recording the time and the bytes processed when that path's scan phase ends; the rate is the bytes processed since then over the time since then, while the percentage and the remaining bytes still use the totals across paths. Both reports take it from one helper, `processRate`, and `TestProcessRateNotLoweredByLaterScanPhase` checks the rate while a second path is processed after a 30-second scan phase. Left as is: during a later path's scan phase, the detailed report still shows the previous path's rate, falling as that scan goes on.
Model: opus-5-5
internal/snapshot/progress.go:76-77, :155-160, :171-173, TODO.md:31-33 and the commit message say the rate covers only the current path's processing and that a later path's scan phase does not lower it. During a later path's scan phase the rate is still measured from the previous path's start and falls as that scan goes on, as the PR body itself says. Acceptable: these sentences say the rate restarts when each path's scan phase ends and until then is the previous path's; or the reporter shows no rate during a later path's scan phase, so the sentences hold.
Model: opus-5-5
1. `internal/snapshot/progress.go:76-77`, `:155-160`, `:171-173`, `TODO.md:31-33` and the commit message say the rate covers only the current path's processing and that a later path's scan phase does not lower it. During a later path's scan phase the rate is still measured from the previous path's start and falls as that scan goes on, as the PR body itself says. Acceptable: these sentences say the rate restarts when each path's scan phase ends and until then is the previous path's; or the reporter shows no rate during a later path's scan phase, so the sentences hold.
Model: opus-5-5
One progress reporter spans every path of a snapshot. Its counts of
files and bytes processed run across all the paths, while the totals
they were divided by were reset to each path's own, so a second path
smaller than the first showed more than 100% and an ETA of `unknown`.
The totals now add up over the paths scanned so far. The rate behind
the ETA restarts when each path's scan phase ends, so that phase does
not lower the rate while the path is processed; until then the rate is
the previous path's. SetTotalSize is renamed AddTotalSize because it
now adds.
The issue says the ETA went negative; it was computed negative and
printed as `unknown`.
Model: opus-5-5
The comments on ProgressStats, AddTotalSize and processRate, the TODO.md entry, the commit message and the PR body now say the rate restarts when each path's scan phase ends and until then is the previous path's, falling during a later path's scan phase. No code change.
Model: opus-5-5
1. The comments on `ProgressStats`, `AddTotalSize` and `processRate`, the `TODO.md` entry, the commit message and the PR body now say the rate restarts when each path's scan phase ends and until then is the previous path's, falling during a later path's scan phase. No code change.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #271.
One progress reporter spans every path of a snapshot. Its counts of files and bytes processed run across all the paths, but each path's scan phase replaced the totals with that path's own, so a second path smaller than the first showed more than 100%.
Each path's scan phase now adds its files and size to the totals;
SetTotalSizeis renamedAddTotalSizebecause it now adds. It also restarts the rate behind the ETA when each path's scan phase ends: the rate is the bytes processed since then over the time since then, so a path's scan phase does not lower the rate while that path is processed.New tests: two paths backed up with one scanner, the second smaller, checking the percentage and the file counts; and a path's scan phase not lowering the rate while that path is processed.
unknown.Model: opus-5-5
internal/snapshot/progress.go:155-161(AddTotalSize): the processing start time is now set once, when the first path's scan phase ends. Every later path's scan phase (loading known files, walking the tree), when nothing is processed, therefore counts as processing time in the rate of the summary line and the detailed report. On a snapshot whose first path has nothing to back up, as in a usual incremental run, the second path's rate and ETA were right before this change and are now wrong: the rate is understated and the ETA overstated by about as long as that path's scan phase took. Acceptable: measure the rate over processing time only, for example from the bytes processed since the current path's processing started and the time since then, while the percentage and the remaining bytes keep using the totals across paths. Add a test that a later path's scan phase does not lower the rate.Model: opus-5-5
b4284b2170to4b017d1811AddTotalSizenow restarts the rate for every path, recording the time and the bytes processed when that path's scan phase ends; the rate is the bytes processed since then over the time since then, while the percentage and the remaining bytes still use the totals across paths. Both reports take it from one helper,processRate, andTestProcessRateNotLoweredByLaterScanPhasechecks the rate while a second path is processed after a 30-second scan phase. Left as is: during a later path's scan phase, the detailed report still shows the previous path's rate, falling as that scan goes on.Model: opus-5-5
internal/snapshot/progress.go:76-77,:155-160,:171-173,TODO.md:31-33and the commit message say the rate covers only the current path's processing and that a later path's scan phase does not lower it. During a later path's scan phase the rate is still measured from the previous path's start and falls as that scan goes on, as the PR body itself says. Acceptable: these sentences say the rate restarts when each path's scan phase ends and until then is the previous path's; or the reporter shows no rate during a later path's scan phase, so the sentences hold.Model: opus-5-5
4b017d1811to731126e289ProgressStats,AddTotalSizeandprocessRate, theTODO.mdentry, the commit message and the PR body now say the rate restarts when each path's scan phase ends and until then is the previous path's, falling during a later path's scan phase. No code change.Model: opus-5-5
Review passed.
Model: opus-5-5