caja-file-operations: fixes the operations timer handling #1758
Conversation
As done for copy/delete jobs, restart the operation timer also for move jobs. Thus preparations (e.g. `scan_sources`) later won't affect the later transfer rate calculation.
When a copy/move operation is created while another operation is already active, the new operation is queued. As the (already running) operation timer of the new operation is not stopped during the waiting period, that period is (erroneously) included in the transfer rate calculation and leads to initially low/slowly increasing transfer rates be shown. Hence stop the operation timer when the (queued) operation is waiting. Fixes mate-desktop#1420 and mate-desktop#1623.
There was a problem hiding this comment.
With this applied, what I found most noticable was that queuing other files for copying now seems to give accurate bandwidth indication, and the waiting file shows "0 seconds" and zero bandwidth as it is not being processed yet. This is a lot better than what we used to get. Ideally the "0 seconds" would be hidden but users will probably know that's a value that can be ignored. Approving and calling for a 2nd review
|
The shown estimate for a queued operation indeed doesn't make sense. The reason is that actually a non-zero transfer rate is one condition to not show the estimate. I fixed this in #1759, aligning to the delete operation case. |
|
Any updates on this or the alternate? Can this one be closed since we have #1759 ? |
|
This and #1759 both affect file operations. However they are not alternative solutions, but address different aspects. So they are needed both. From my side, this MR is ready to be merged (however there still has been no second review). |
Essentially fixes the bug that for queued file operations the wrong transfer rate is shown.
To reproduce the issue/check the fix, start a (larger) file copy/move operation and then start a second one, while the first one is still running.
Fixes #1420 and #1623.