ADFA-5160: anchor clone-receive progress to the dry-run total - #420
Merged
Conversation
The receive bar was driven by rsync's --info=progress2 percent, which divides by an estimate rsync keeps revising upward as it discovers files. The percent climbed toward 99% and dropped back each time that denominator grew — the "goes to 99% then starts over" the ticket reports. Anchor the bar to a fixed denominator instead: the dry-run's bytes-to-transfer (what rsync computes for this transfer up front, resume-aware), with rsync's transferred-byte count as the numerator. The percent is monotonic and held at 99% until rsync reports success, so 100% shows only on real completion. The QR size estimate is not used — it reflects the sender's initial install and can drift as content changes. Computed once in the transport (RsyncManager), so both receive paths (ReceiveController and CloneFragment) get it without duplicating the smoothing; callers only supply the total. Both already run the dry-run via startProbe, so the figure is available; if it were ever 0, the transport falls back to rsync's own percent. SyncListener.onProgress keeps its signature. - RsyncProgress: also parses the leading transferred-byte column (+ test) - TransportEngine.startClient: new expectedTotalBytes argument - SyncStateViewModel: exposes the dry-run total via getPendingBytes() Verified: Java sources parse-checked; RsyncProgressTest extended. On-device clone pending.
The receive bar and ETA were both driven by rsync's --info=progress2, which
divides by an estimate rsync keeps revising upward as it discovers files.
The percent climbed toward 99% and dropped back each time that denominator
grew — "goes to 99% then starts over" — and the ETA, computed against the
same per-file plan, jumped the same way.
Anchor both to a fixed denominator instead: the dry-run's bytes-to-transfer
(what rsync computes for this transfer up front, resume-aware).
- Percent: rsync's transferred-byte count over that total; monotonic,
held at 99% until rsync reports success, so 100% shows only on real
completion.
- ETA: (total − transferred) / current speed, so it counts down against
the same whole-set total rather than rsync's shifting per-file plan.
The QR size estimate is not used — it reflects the sender's initial install
and can drift as content changes.
Computed once in the transport (RsyncManager), so both receive paths
(ReceiveController and CloneFragment) get it without duplicating the logic;
the callers only supply the total. Both already run the dry-run via
startProbe, so the figure is available; if it were ever 0 the transport
falls back to rsync's own percent and ETA. SyncListener.onProgress keeps its
signature.
- RsyncProgress: parses the leading transferred-byte column and the speed
column; adds whole-set ETA formatting (+ tests)
- TransportEngine.startClient: new expectedTotalBytes argument
- SyncStateViewModel: exposes the dry-run total via getPendingBytes()
Verified: Java sources parse-checked; RsyncProgressTest extended. On-device
clone still pending.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The receive bar was driven by rsync's --info=progress2 percent, which divides by an estimate rsync keeps revising upward as it discovers files. The percent climbed toward 99% and dropped back each time that denominator grew — the "goes to 99% then starts over" the ticket reports.
Anchor the bar to a fixed denominator instead: the dry-run's bytes-to-transfer (what rsync computes for this transfer up front, resume-aware), with rsync's transferred-byte count as the numerator. The percent is monotonic and held at 99% until rsync reports success, so 100% shows only on real completion. The QR size estimate is not used — it reflects the sender's initial install and can drift as content changes.
Computed once in the transport (RsyncManager), so both receive paths (ReceiveController and CloneFragment) get it without duplicating the smoothing; callers only supply the total. Both already run the dry-run via startProbe, so the figure is available; if it were ever 0, the transport falls back to rsync's own percent. SyncListener.onProgress keeps its signature.
Verified: Java sources parse-checked; RsyncProgressTest extended. On-device clone pending.