I had several disk drives plugged in, and while copying lots of video files onto a USB stick, I accidentally pulled it out instead of intended other disk.
The Opus' "Copy File" reported an error "The device is not ready (21)" and upon reinserting the same USB stick (into the same USB port), the "Retry" button doesn't help (the same error immediately pops up).
However, clicking the "Skip" continued copying the rest of the files.
Note: I did allow time for USB stick to be properly recognized etc. before clicking the "Retry" (multiple times).
If it was mid-way through writing a file, the retry would be on the write operation at that stage, which will fail because the old file handle became unusable when the disk was removed. It would need a restart (of the file) at that point, rather than just a retry of what it was doing.
Not impossible, but I'm not sure how reliably we could detect that situation, as well as the many places and different errors/conditions it could create.
Best not to remove the drive while things are being written to it. If a drive is yanked out, there could even be errors we wouldn't be able to detect since the filesystem or hardware buffers may not have been flushed to it yet (depending on how it was mounted), on operations which the operating system already reported as successful. It's a bad situation in general.
Perhaps in such situation ("device not ready" again after Retry for that same file) Opus could try to copy the file as a new one from scratch (and if that fails then it's a legit device failure).
btw I've tried the chkdsk on the USB stick and it didn't find any problems (perhaps it auto-fixed it in the background, or simply a journaling nature of NTFS prevented filesystem corruption).
In any case, Retry now gets stuck on that file, while the "Skip" resumes copying the other files, so user must remember to copy that file manually again which can be annoying.
I'd like to agree. The retry button is useless in case a drive gets lost.
Losing a drive in the middle of a copy/move operation can have different reasons, that's why it still happens and will happen in the future. It might be network, hardware failure, just bad cable etc. If I remember "disk full" yields the same situation (you cannot really retry/continue after fixing the problem).
We actually already have handling in some cases which will cause a full restart of the file rather than retrying the last write, but only for specific error codes (ERROR_FILE_INVALID and ERROR_NETNAME_DELETED). I'll add this for ERROR_NOT_READY as well.
If a drive is yanked out, there could even be errors we wouldn't be able to detect since the filesystem or hardware buffers may not have been flushed to it yet (depending on how it was mounted), on operations which the operating system already reported as successful. It's a bad situation in general.