Ticket #3205 (new defect)

Opened 5 years ago

Last modified 4 years ago

Failed copy/move operations make ETA inaccurate

Reported by: Nick Owned by:
Priority: minor Milestone: Future Releases
Component: mc-core Version: master
Keywords: Cc: onlyjob@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:


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.

Change History

comment:1 Changed 5 years ago by onlyjob

  • Cc onlyjob@… added

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.

comment:2 Changed 4 years ago by 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.

Note: See TracTickets for help on using tickets.