Failed copy/move operations make ETA inaccurate

[Nick]

When I copied ~400GB of files, some of the files were corrupted and MC subsequently skipped them. However, the overall progress (ETA) didn't reflect this. The result was that at the end of the copy operation (12 hours later), the operation suddenly finished even though the ETA was still at ~3 minutes. This gave the impression that the operation had finished prematurely, when infact the ETA simply hadn't taken the skipped files into account.

It would obviously be better for the ETA to reach 0 when the copy/move operation finishes.

Also, the number of processed files reading doesn't take skipped files into account, meaning at the end of the copy/move operation it will say something like '497/500 files'. I think the processed files count should include skipped files, so that at the end of the operation, the count would be 500/500 files every time, otherwise it seems like the operation has finished prematurely.

[onlyjob]

Just yesterday when I was copying over 50000 files from slow network location I've noticed that ETA was shown as follows in MC_4.8.12:

Time: 0:16.42 ETA -2147483648:-2147483648.-2147483648 (11.39 KB

So I hope ETA values can be checked for overflows etc.

[SkunkWorks]

In the above example, it is said the '497/500 files' should actually be '500/500 files'.
In my opinion, it should end with '497/497 files', if there are 3 files skipped.

A change of 3 files out of 500 can be seen as a minor bug, but imagine that you are refreshing a destination directory tree and 250 of 500 are skipped. Or 450 of 500...

I think each skipped file shoud be removed from the total number of files AND it's volume substracted from the total volume. That way, the estimated speed would allways stay correct, and the estimated time would be updated at each skip.

[andrew_b]

Replying to cri:

A very small reget bug I only noticed now: when doing a "reget", the ETA time is always overestimated; I haven't looked at the code, but it seems the ETA is wrongly computed using the size of the whole file; of course it should be computed only on the remaining part still to be transferred.

[cri]

Replying to andrew_b:

Replying to cri:

A very small reget bug I only noticed now: when doing a "reget", the ETA time is always overestimated; I haven't looked at the code, but it seems the ETA is wrongly computed using the size of the whole file; of course it should be computed only on the remaining part still to be transferred.

(thanks for pointing me to the right ticket)

But this should be then universal, so not only FTP transfer and was present before, right?

I noticed the wrong ETA using FTP reget, so this might or might not be related to the skipped files scenario described by OP. I can confirm the problem was already present before the changes introduced to fix #4563