Since a couple of weeks I have an issue with copying or moving files on my C: and D: partitions on my NVME 2TB SSD. With DirOpus I get write speeds of like hundreds of kB/s, whereas in the past it was like a 1000 times faster. This only occurs with DirOpus, not with Window Explorer and it only occurs on my NVME SSD. Writing from the NVME SSD to an external SSD does not have this issue.
My SSD is fine, I have scanned and rescanned it several times. It has about 100GB free space.
I run the latest Windows 11 update and all my drivers are up to date as well.
If I run Crystal Disk Mark on my NVME SSD it return normal values.
So I am guessing it is some issue with DirOpus but I cannot figure it out.
I have been using DirOpus since before 2015 with more or less the same settings and I have not changed a setting in months.
I have also tried un-installing and re-installing DO12, but the issue remains.
I also un-installed DO12 and installed DO11, and the issue is still there.
BTW I have no AntiVirus running, indexing is turned off and to be clear the only thing that was changed in the last couple of weeks were Windows updates and DirOpus updates. I don't have a Windows Restore point to go back to unfortunately.
Nothing about how Opus copies files has changed recently, so if it was working at full speed until recently then there must be a change somewhere else, either in the system or the Opus configuration.
Did you change any of the copy buffer settings in Opus recently?
What kind of files are being copied?
Is it a few large files or lots of small ones?
Have you tried copying the exact same files to the same places in different software? (Try a few times, alternating between programs, in case caching speeds up subsequent copies of the same files.)
I have not changed the buffer settings.
It does not matter whether I copy small (100kB) or large (10MB) files.
As I have written, doing the same thing in Windows Explorer works fine.
10MB is still very small when it comes to NVME speeds. The majority of the time will be spent opening files and setting attributes and timestamps, not copying data, and the reported copy speeds will be fairly meaningless.
That thread is completely unrelated, and was locked because people were arguing and talking nonsense in the thread (some of which was deleted to stop the back and forth).
Delete to recycle bin has nothing to do with file copy speed, is handled entitled by the OS (including the “calculating” stage that has the delay; I have no idea what the OS does during that stage as we play no part in it whatsoever), and the issue that thread is about affects many other programs on machines that don’t even have Opus installed, which you can discover from a quick google search.
I have no coding insights or experience, so I have no reason whatsoever to doubt anything you say.
I was just thinking that 'deleting' is in fact copying (to trashbin) too.
Which made me think about the other (locked) thread.
It was just my brainfart on the matter being curious.
(and also me being a bit sensitive about 'cancelling' and shutting down discussions)
Deleting to the recycle bin just renames the files into the recycle bin folder. It doesn’t create a new copy, it moves the existing file to another folder on the same drive. Plus some bookkeeping and whatever else Windows does, which no one outside Microsoft seems to know.
We don’t lock threads often here, which you can see just by looking at the forum.
Let’s get back on topic, as this has derailed the thread.
Every file has overhead that is unrelated to its size, so when you are dealing with small files its the number of files that matters more than their cumulative byte count. One billion single byte files will take a lot longer to copy than a single file containing 1 GB of data.
(Edit/Leo:) The time estimate may also be less accurate with lots of small files, as it’s hard to predict how long they’ll take. You can also speed things up with lots of small files by turning off copying of extra metadata and attributes, which not all programs will copy, and which can dominate the copy time with a large number of tiny files.
I know this of course, but I think I had made it clear that I have never had this issue before in the 10 years or so I have used DO. And the fact remains that Windows Explorer has no issued doing exactly the same thing.
There are lots of variables when copying files, especially when copying lots of small files. Which datestamps, attributes and metadata (e.g. NTFS ADS for file comments and Opus labels) are copied can have a huge impact when copying a large number of small files, and may differ between programs.
Do you really have no antivirus at all, or is the built-in one (Defender) still there? FWIW, Defender also has a privacy side to it which can cause problems and is configured separately to the antivirus side.
If you have Opus (or something else) looking at the destination folder as the files are being copied into it, that could also be a factor. For example, some Opus columns will cause the files to be opened to get data out of them (and could in turn invoke video codecs and similar things, which can slow things down if they don't work right, although I'm guessing the small files aren't video files/extensions).
Also, what are you judging the speed on? The reported speed and time estimates won't be very meaningful if the files are all tiny. Have you waited to see if the copy completes in a similar time to when it's done in File Explorer?
(Try File Explorer and then Opus, too, as doing it the other way around could give a false impression Explorer is faster because some or all of the tiny files are already cached in memory and don't have to be read the second time.)
You are overlooking the fact that until a few weeks ago I never experienced this issue when doing the same file operations.
Something has changed in Windows and/or DO and I have no idea what.
File copying speeds are based on my experience. If Windows Explorer does it in a few seconds, DO should not take two hours, no matter what file types or size.
I have always used DO because of the superior file copying and have simultaneously copied GB's of files to and from my SSD withoug any hickup.
BTW it's not only that the copying is incredibly slow but the copy window is very unresponsive and aborting the copy needs multiple clicks, which sometimes results in DO freezing and I have to FC it.
As I said, nothing changed in Opus recently w.r.t. file copying. We are very conservative about changing that code, due to things like this.
So it's most likely something in Windows, drivers, or some other software that is getting involved.
That detail would have been good to know at the start! It suggests something is interfering with the process. If you don't have any antivirus etc. installed, do you have anything installed that changes how windows look/behave? Anything which moves windows around or adds commands to their titlebars or things like that? We have seen several tools like those cause problems with our progress dialogs, apparently because they didn't expect the combination of windows and threads that we use with them (which is unusual, but not against the rules).
Make some process snapshots while it is in a frozen state and not responding to button clicks and we can probably tell you what's causing it from those.
Did you also have a look at the NVME's temperature?
Few weeks ago I had my first dying SSD, it ran normally on copy-operations and in my workflow, but when trying several backups with Reflect, speed always reduced suddenly to 6 MB/s and lower (health tools still reported good condition). I did a clone onto new SSD, problem gone.
Guys, my apologies. I had a closer look at the running processes and I saw that AdAware was running. I never had an issue with this AV previously and I have been using it for years, but when I uninstalled it the copying issue went away and all is well again.
Still, I cannot understand why the issue was so specific with smaller files and on one drive only.
It looks like one DMP file was made and then you sent five identical copies of it, which means we can't tell very much from them as we don't know if the code was stuck somewhere or just happened to be there when the only DMP was made.
