I have a USB hard drive that is failing. I bought a new one and wish to copy all the contents from the flaky drive to the new drive. There are a few terabytes to copy.
D. Opus is great for this, especially with the Unattended operation feature. After a pass, there were a few hundred files in the error list, since the flaky drive flaked out momentarily a few times.
I pressed Retry and away it went copying files. However, I noticed something that happens on Retry that does not happen in the original Copying.
It has been running for almost three hours. The error list had 477 items (apparently). Opus, however, is actually copying many more items than that, which I presume is because some of the items were folders that had many items within them.
Here is the current status screen (this is actually from the second time I pressed Retry):
As you can see, it shows that 1,872 out of 477 have been copied. Also the progress bar is at 100%.
What I don't understand is why Opus doesn't traverse and calculate and show the actual number of items (and total size) that need to be handled? It also does not show the estimated time remaining (of course). All of that is displayed on the original Copying window.
I would like to suggest that it also be handled the same on the Retry Copying window. Right now there is no way for me to know if it has another 10 minutes or 10 hours of work left to do.
We've seen it but don't know enough to reproduce it.
If you can give some exact steps (that don't require failing hardware), we might be able to look in more detail sooner. Other than that, it's in our list to investigate when we have time.
I don't think failing hardware is necessary to reproduce it. Anything that causes an error during unattended operation should make it happen, such as trying to move a folder of files and folders where one internal folder is locked so can't be moved. I suppose one could also reproduce it by unplugging a source USB drive in the middle of the copy and then reinserting it before pressing Retry.
In any case, perhaps I didn't explain it clearly. The problem appears to be that on "Retry", dopus assumes the error list in hand is all that is needed in terms of the scope of items to treat. So it uses the number of them as the number to display. The logic error then would be that dopus doesn't traverse the items in the error list and find folders that need to be recursively traversed in order to get the actual number (and size) of items that need to be handled (i.e., copied or moved). If it did that, it would display the correct information, progress bar and time estimate, as it does on the original Copying window.
That's what I meant when I said it should be handled the same as the Copying function. A code review of the Retry function should be enough to confirm if my guess is right or not.
BTW, it occurred to me that DOpus shouldn't even need to retraverse (except to be extra sure nothing changed on the source device between the first attempt and the retry). ALL the information was already obtained in the original traversal to count the items and sum up the sizes. In that case, the logic error would be in not retaining the information already gathered for all the failed folders. If it were retained and used on the retry, it would accurately show how much is left to do with an estimate of time remaining.
Is that something that is straightforward to check and fix?
