I was using DO to copy a bunch of files from one external USB 3.0 drive to another external USB 3.0 drive.
Intermittently, I would hear my Win7/64 make a USB "disconnect" sound and would get a "File not found" error. It turns out the "destination" drive would suddenly disappear, causing the "disconnect" sound and that drive would also disappear from the DO left directory tree, then a few seconds later it would return.
What was weird is that the drive that intermittently disconnected was the "Destination" drive. So I am confused why it would cause a "file not found" error - I would expect such an error if the "source" drive was suddenly disconnected.
Anyway, even if I clicked "Retry" after the drive came back online, it would still fail to copy that file - I would have to click "skip" for DO to skip that file and continue copying the rest of the files. Why couldn't DO recover the copy operation for that file?
Opus just reports the errors that come from the file system, and I guess "file not found" is not really inaccurate since the destination file can't be found (since the drive it is on has gone).
I've actually been meaning to look at improving recovery in this sort of situation for a long time. We'll see what we can do in the next update.
I've encountered this situation myself, and it seems DO's Retry doesn't really do anything when it encounters this.
I assume retry simply tries to continue from where it is, rather than restarting the copying of the current file.
I wouldn't mind if it did the latter when the former isn't possible.
Detecting the disappearance/reappearance of a drive together with the "strange" error should be possible.
Maybe it should pause the copy if the target disappears.
In my experience I've found that USB3 using Win7 damages drives/flashdrives because they have a tendency to be sent to sleep
while they're written to. They work perfectly in a USB2 port though (unless they're damaged by the above).
If the drive is spontaneously disconnecting while data is being written to it, I'd be worried there may be errors the operating system (and thus Opus) isn't detecting.
Improving how Opus handles this definitely makes sense, but if it's something your hardware/drivers do regularly, I'd also look at finding a way to stop it happening, since it cannot be good. The system event logs might indicate why the drive disconnected, and I'd also check for firmware updates for the drive/controller itself and USB driver updates on the PC side.
Changing the copy buffer size in Opus can also help sometimes, as some poorly designed USB devices seem very sensitive to buffer sizes, even though they should not matter. (That usually only affects cheap memory sticks and not harddrives, though.)
Disabling Non-Buffered I/O can also help with some devices, although that has been disabled by default in the most recent versions of Opus 11, for increased compatibility, so it's probably already off if you're up-to-date and haven't turned it back on.
Don't rule out a loose USB cable or connector, either. And if it's a USB-powered drive, using a powered hub can sometimes help, if the PC's ports are not supplying enough power, or if it's plugged in via an unpowered hub which is reducing the amount of power it gets.
Trouble is that this seems to be a well known issue with W7, and apparently has been since before the initial release. Considering it don't seem to matter if the USB3
is by Intel, ASMedia etc, the blame seems to be on W7 (not sure if W8 fixes it).
Googling the issue gives quite alot of people asking how to "cure" it, then getting nowhere fast.
There doesn't seem to be any option that actually affect that sleep behavior, even if it apparently is supposed to (selective suspend etc).
In my case that off/on behavior eventually (after <1 hour or so with copy, sleep, reinsert, copy...) caused windows to say
the flashdrive (Kingston G4 128GB, FAT32, not fake) was writeprotected..iow, damaged beyond repair. I got it replaced for free
by the shop, but I try to avoid using USB3 because USB3 is unreliable in my experience.