DOpus handling of RAR archives is very useful, allowing direct archive browsing, but there are couple of problems:
Open the archive in DOpus, select folders of files from it, copy to clipboard. When I go back (archive is no longer opened in DOpus), trying to paste doesn't work.
Copying from opened archive to another DOpus window is very, very slow with archives with many files. From what I have seen, DOpus is starting WinRAR process for each individual file, and each file takes an extra long time to extract. Archive during copy process should be open by one WinRAR process. With this, large archives unpacking is unusable with DOpus.
DOpus is not handling ZIP archives like it does RAR. Since DOpus uses WinRAR (from what I have seen), why no ZIP support, WinRAR supports hundreds of archive, yet DOPus works with RAR only.
When I copy files (copy only, I don't use move for archives), I see WinRAR icon flashing in the system tray for each file, and that's why I think that WinRAR is used. And that explains very low speed of copying from archives if DOPus opens new WinRAR instance for each file.
Thanks for the ZIP, it was disabled in the settings, it is OK now.
I did some more detailed testing, RAR problem is not happening with every RAR archive, only some of them. If the RAR archive is created with old 2.0 RAR version, it works OK, but the problem is with newer 3.0 archive types. I even tried converting old format to new, and problem showed up also.
How do you create a RAR 3.0 format archive? The archives I have created with WinRAR 4.0 say "Version to extract: 2.0" when I look at their properties in WinRAR.
I have no idea . I have some archives that are listed as 3.0 and some 2.0, both created with WinRAR 4.0. But, version is not the problem. I tried several more archives I have with a lot of files, and some are acting as I described, some are don't I see nothing in the archive properties to point to a difference.
See if you can use Task Manager or Process Explorer to see what command-line WinRAR.exe is being run with when it happens. That might shed some light on it, perhaps.
I used process explorer to capture the process. It is running winrar.exe (x64) I have installed in my Windows 7 (Home Premium x64, if you need that). I have WinRAR 4.0 installed. For archive with 600 files, program detected that winrar.exe has been started 600 times. It took 2 minutes to unpack that archive (102 MB). Unpacking directly with WinRAR took 3 seconds. As I said before this is happening with some RAR archives, and I have no idea what exactly is the difference.
I didn't save the sessions from that, but it is a fairly standard command to extract single file from one archive to a set destination. That's why it is slow, it definitively is unpacking one file at the time.
I can't see Opus itself generating such a command-line since Opus does not contain any code to tell WinRAR.exe to extract files.
Opus only calls WinRAR.exe to rename, delete or add files within an archive; never to extract files from an archive (that is done without using WinRAR.exe).
A couple of things to try:
Can you go inside of RAR files in Windows Explorer? (I don't mean opening them in WinRAR, but opening them within Explorer itself, as if they were folders.) If so you must have a RAR virtual-folder shell extension installed, and maybe you're using that rather than Opus's own RAR support, which would explain the difference.
Does it only happen when you use Ctrl-C, Ctrl-V and/or drag & drop to copy the files? What if you select the files and then click Copy Files on the Opus toolbar? If it happens when using the clipboard and/or drag & drop, but not when you click Copy Files, then the extraction may be happening via a file-copy/drop shell extension. (I forget the exact name of this type of extension, but if you use ShellExView it should be easy enough to find the archive-related extensions if there are any.)
. I have some archives that are listed as 3.0 and some 2.0, both created with WinRAR 4.0. But, version is not the problem. I tried several more archives I have with a lot of files, and some are acting as I described, some are don't I see nothing in the archive properties to point to a difference.