Closed barkawa closed 2 years ago
Interesting, I've never noticed that. Can you share what OS / terminal are you using? After it goes back to 0, does it progress again slowly from 0, or does it jump back to the original (correct) position and continues from there? I just try to figure out if it is a problem with computing the progress, or maybe just a rendering problem.
Ah, wait, I think I know what you mean. So indeed the progress bar does go back to zero when the new phase starts. That is intentional, because the progress bar shows the progress of the current phase. The name of the phase is displayed on the left, it changes with each phase, so I thought it was clear.
I think I could improve it by reporting the current number of the phase together with the total number of phases, e.g like this:
[2/5] Grouping by size... [=======> ]
WDYT?
Hi, sorry for the late response, I've been quite busy lately. Your suggestion looks good, and I think it's a nice UX improvement, however my problem was of a different nature. It occurred only during the "grouping by contents" phase, where the progress bar went back to zero multiple times, but it was still "grouping by contents", it didn't change phase.
Unfortunately I can't reproduce the error with synthetic test files on my main machine, and the original files that the error occured with are already deduped.
When the error occurred my setup was the following:
I'll try the test files on the Pi next. Maybe ssh is doing something weird.
While grouping by contents the progress bar goes up for some time, and then jumps back to zero. This repeats multiple times, which at first made me beleive something must be going wrong, but eventually fclones exited successfully.
I find this to be quite confusing behaviour for a progress bar. I'm not sure if it's an error, or intentional.