I'm copying some files over to a storage HDD to prepare for an SSD wipe and transfer to a new PC. During this file transfer I noticed that there is a "time elapsed" clock but no "time remaining" estimation. Can this feature be enabled somewhere?
Time remaining may not appear in some situations if Opus is unable to estimate it accurately.
(I'm not sure why that would be in this particular case.)
Do you see the time remaining estimate in other cases (e.g. copying a few large files), or is it never shown for you?
Is Preferences / File Operations / Progress Indicators / Count files in folders before copying for turned on for the type of drive involved?
Just tested with the drives in question. C: is a Samsung 830 SSD and G: is a Seagate IronWolf 10TB NAS HDD. It seems it actually works normally and I just never paid attention to it because I didn't do transfers that lasted this long.
I did get some "access forbidden" types of messages when I copied the files in the original copy event but I also got one with this second test so it's probably not that.
As my last test, I will do the a similar transfer to what originally introduced the issue.
Here we can see that the timer gets stuck. It was 5:31 almost right at the start and it's still stuck there. It doesn't change at all. This is probably similar to what happens with the original transfer. In any case, this is not use critical for me since it works most of the time.
It's probably copying thousands of tiny files, but in an overall job where there is a large amount of data to be copied, in which case the time estimate doesn't work well during that period. (Each tiny file represents ~0 progress, as most of the overhead is creating the file itself, and the amount of data copied is tiny compared to the total amount being copied.)
Can we get this looked into? If Explorer does it DO should correct? Yet I'm not seeing any time remaining on my days long copy in DO.
I think we already did that in the last 8 years. 
The time it takes to create each file is factored into the time estimates to make them more accurate when copying lots of tiny files.
If you're seeing problems with time estimates, we need a lot more detail about the copy being done and how to reproduce what you're seeing.
Also note that if we known an accurate time estimate cannot be generated (e.g. because the copy speed is fluctuating too much) then we won't show one at all, as an inaccurate estimate is pointless. When you say this works in File Explorer, does it really work, or does it just display a bad time estimate that's of no use?
(Preferences / Miscellaneous / Advanced: [Filesystem] copy_allow_delegation can also affect things here. If file copying is delegated to the shell then we have a bit less information to work with, since it's not us creating and copying the files directly, although it shouldn't make a difference to the estimates in most situations.)
1 Like
I'm not seeing any estimate. I'm copying large video files and I'm getting about 1.08mb/s constantly. How can I know I'm getting a bad estimate in Explorer? Why do you assume it's bad? I would suspect that like you say smaller files would be more erratic (sp). The only way I could know it's bad is to verify it after everything is copied but then the dialogue disappears so if I'm not sitting there at that moment focused on that dialogue I won't know. Even a bad estimate has some value moreso than none.
The thread was about an issue with lots of tiny files that copied instantly (which was fixed). You're doing the opposite: Large files that take a very long time to copy.
If the time estimate is so large that it's over 999 hours (i.e. 41 days), we won't display it because it's probably nonsense. That's probably what's happening.
1MB/s is ridiculously slow for a file copy to a USB device on modern hardware, so maybe it really will take more than 999 hours.
Do you really want to wait over a month for a file copy? Instead, you should upgrade whatever the bottleneck is (the device and/or the USB hub and/or port) that's causing the copy to be so slow. Even if you have to wait for the new hardware to be posted to you, the copy is going to complete a lot faster that way.
There's not even a total bytes display so you can't even calculate it yourself. All it has is a file count which is really worthless because there's absolutely nothing to quantify what that means. I don't understand why you've chosen to break from your Windows Explorer equivalence?
This wouldn't be anywhere near 41 days. It's 311 files total. It's done 18 files in 5 hours. 4+ days assuming they are all the similar in size which I don't know but I would doubt.
The drive is in a cautionary state so I need to offload it. It has a Current Pending Sector Count of 1. This is a mechanical failure it could go up or down at this point. It could fail or maybe get better so I'm just trying to get it done at this point then I'll look into what other problems exist in the USB chain.
Even cheap USB sticks will write at 30MB/s these days. 1MB/s is very, very slow. (Unless the problem is the source drive failing and having to retry constantly, which would make time estimates fairly useless as there's no way to predict how many retries will be required along the way.)
If the total size isn't being reported, calculation may be turned off in Preferences / File Operations / Progress Indicators / Counting Files.
(I'm assuming this is a normal file copy from one drive to another, not involving drag & drop from another program or archive, which can complicate things. Although those cases usually show total size as well, it isn't available in every situation.)
Yeah, I understand there are USB issues. I'm not going to redo this copy after it's done so for this particular purpose it's too late but in general I'd like some indicator of estimated time even if it's not perfect. Like I said earlier I'm not sitting there watching it so I probably won't detect smaller discrepencies. Now if it's off by a month I might notice.
You are using the same estimate as Windows currently? I get why it would be off when you're copying lots of tiny files. Still given the challenge I'm sure I could come up with some code that would correct for what I'm guessing is simply calculating time based on total bytes divided by the average transfer speed.
I don't think the drive is the problem because I'm not seeing any other errors. Something is wrong because I have 2 other drives on that same chain that get the same throughput.
Everything under file counting is checked.
This is a synch operation from DO.