I appreciate the effort you put into optimising Dopus for large file operations done in other programs a few versions ago, but unfortunately it seems some more work needs to be done.
I just created (not with Dopus) 7,462 symbolic links in a folder on an SSD while that folder was open (with a folder tree) in Dopus. These links were created in 256 subfolders with a roughly equal distribution of the links per folder (~30 per folder). These folders and links are a couple of subfolders deep on C:\ (an SSD), and the destination of these symbolic links is a bunch of files in a subfolder at E:\Blah\Blah**, where both * and * can be any hexadecimal representations of a byte (ie: 00 to FF). So it’s linking to a subfolder of a subfolder that contains 256 subfolers, each with 256 subfolders of their own.
This was about 5 minutes ago , and the lister that was viewing the folder containing the folders with ~7000 links is still using 12.5% CPU (one full core), and is unresponsive.
I managed to browse to the folder with another lister, but double-clicking the folders in the detail/list view doesn’t open them. Clicking on them in the folder tree opens them however. Trying to open any of the symbolic links created doesn’t seem to do anything initially, but then about 30 seconds later, they load.
I just killed dopus.exe, loaded it up again, and everything is fully responsive. The folders on c:\ with the symbolic links browse to almost immediately, and double-clicking any of the symlinks opens them immediately too.
Seems like Dopus is getting bogged down updating some sort of internal structure during, directly after, and for at least 5 minutes after an external program performs many file operations.
Let me know if you need any clarification or information.