New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qvm-copy-to-vm incorrect progress report #1519

Open
kirill9000 opened this Issue Dec 15, 2015 · 3 comments

Comments

Projects
None yet
6 participants
@kirill9000

It copies file fully, but reports in a manner like: sent 10004/10005 KB or even sent 0/1 KB for small files and that may confuse some users.

@Rudd-O

This comment has been minimized.

Show comment
Hide comment
@Rudd-O

Rudd-O Dec 18, 2015

Round up? That might be the correct answer.

Rudd-O commented Dec 18, 2015

Round up? That might be the correct answer.

@marmarek marmarek added this to the Release 3.0 updates milestone Jan 6, 2016

@bnvk

This comment has been minimized.

Show comment
Hide comment
@bnvk

bnvk Feb 18, 2016

Agree. This discrepancy has made me question if the copying was completed correctly of if some file failed to finish!

bnvk commented Feb 18, 2016

Agree. This discrepancy has made me question if the copying was completed correctly of if some file failed to finish!

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Apr 22, 2017

Member

@marmarek There are cases where the report is correct, so Rudd-O's proposed solution wont work.
I think the problem arises because the target figure comes from du operation on the sender, and the "progress" figure comes from the recipient, using a division in C (x/1024) to get Kb value. Division in C always truncates to zero so there will always be the possibility of discrepancy.
The only way I can think of guaranteeing there would be no discrepancy would be to write after a successfull copy , duplicating the target figure (sent TARGET of TARGET ), which is pretty monstrous.

Member

unman commented Apr 22, 2017

@marmarek There are cases where the report is correct, so Rudd-O's proposed solution wont work.
I think the problem arises because the target figure comes from du operation on the sender, and the "progress" figure comes from the recipient, using a division in C (x/1024) to get Kb value. Division in C always truncates to zero so there will always be the possibility of discrepancy.
The only way I can think of guaranteeing there would be no discrepancy would be to write after a successfull copy , duplicating the target figure (sent TARGET of TARGET ), which is pretty monstrous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment