Sync transfers (redux) for realistic progress bar updates

[vjr]

Fixes #2818

Alternative (simpler) approach to #2819

[vjr]

@jeremypw hmm i wonder if this might be a better (way better) approach to fix the issue? Thought to attempt this while working on #2827 to fix #137

[jeremypw]

Certainly simpler! But as far as I can see , when moving files your sync function is only called for local moves not for moves e.g. onto USB stick which is the opposite of what is needed?

I must admit it is hard to get one's head around all the C code 😞

As far as I can see move_files_prepare actually moves files in some cases (g_file_move succeeds without fallback flag) so the name is misleading. When this fails it calls copy_move_files and eventually g_file_move again with different flags allowing fallback. In the latter case the callback is still copy_file_progress_callback.

[jeremypw]

It would be nice to get the progress window to update in the middle of transferring a large file. At the moment it just freezes.

[vjr]

It would be nice to get the progress window to update in the middle of transferring a large file. At the moment it just freezes.

This appears to be the g_file_copy () invoking the callbacks very quickly likely due to the kernel buffer cache? So the "report copy move progress" function returns early because 100ms has not elapsed yet.

Should be addressed in f2a1017

It always reports the final callback/progress invocation and added a special case progress details text like "Please wait, finishing copy..."

[vjr]

Certainly simpler! But as far as I can see , when moving files your sync function is only called for local moves not for moves e.g. onto USB stick which is the opposite of what is needed?

I must admit it is hard to get one's head around all the C code 😞

As far as I can see move_files_prepare actually moves files in some cases (g_file_move succeeds without fallback flag) so the name is misleading. When this fails it calls copy_move_files and eventually g_file_move again with different flags allowing fallback. In the latter case the callback is still copy_file_progress_callback.

What are you doing that you do not see the syncs/progressbar updates happening for USB stick? Can you tell me the file size(s) and what steps you are doing? Seems to be working in whatever scenarios I've been testing.

[jeremypw]

@vjr The freezing mid-bar I previously noted does not seem to be happening now, thanks. I noticed the new "finishing moving ..." message when moving a large file onto the USB stick. Copying the same file onto the same stick was much slower when replacing an existing copy of the file and behaved differently in that the progress bar completed quickly (a few seconds) but then remained on "Please wait finishing copy ... " for a very long time even though the file transfer seemed complete as judged by the progress bar and the file size reported on the destination (after refresh). It eventually completed after 10 - 15 minutes. So the realistic progress updates do not seem to be working in that case.