Hi, I have been using DOpus 6+ at home since my Amiga days. Somehow I managed to live without it at work for some months now, but yesterday I installed it at work using a demo license...
The reason I installed it was that WinZip took forever to replace one or two files in a few megabytes large jar-file. The problem is, DOpus doesn't seem to be faster! After 5-10 minutes of no progress I shut it down (abort didn't work). Then I tried Total Commander, and it can do it in just a few seconds every time.
A friend suggested that I try to disable the batch-options in the zip file settings. Suddenly DOpus worked faster too, but only once! Next time I tried, it just got stuck on the first file, and nothing happened again. Does anybody recognize this problem? Am I doing something wrong? Is there a workaround?
Maybe turning off use temporary file when copying to ZIP files (safer but much slower) will speed things up?
I suspect, though, that if the file being replaced is not at the end of the file then the whole Zip file will be re-written anyway, which is presumably the cause of the slowness.
That said, if the zip file is only a couple of megabytes then it shouldn't take that long with or without a temp file, unless the drive your temp directory (or the destination directory) is on is very slow, full or fragmented.
Currently I have everything listed under Advanced disabled. I had Use batch* enabled to begin with (then I didn't even get a progress indicator).
I have only tried it on one file (though, several versions of it ), the same that I used TotalCommander on. It's accessed through a ClearCase view, so it's kind of a slowed down network drive.
I just tried again, this time I copied the archive to my local harddrive before I replaced three files in it. Much better, it took just under 30 seconds. But now TotalCommander did it in less than one second! It seems like DOpus uses a much more I/O intensive way of working. Wonder how it managed to do it quickly once on the ClearCase view...
I tried Procmon and the most obvious difference is that DOpus reads the file one byte at a time, except for once in a while when it reads 15 bytes ahead, and then continues reading byte for byte, reading those 15 bites over again.
TotalCmd reads different lengths. It varies a lot, but say around 50 bytes at a time average.
Maybe it's just that. You get a much larger overhead reading one byte at a time, especially in this case over the network to a ClearCase server.
Well, the OS and file system are the same in both cases, but maybe there are different ways you can tell windows to open the file, I don't know. Will you have a look at it, please?
I can't look at it myself (I just answer questions here and don't work on Opus), but if you drop GPSoft a support request ( gpsoft.com.au/Support.html ) hopefully they'll look at it.
They may not have much control over how the file is opened. It depends how the Zip library works. But there may be something that can be changed, or a workaround added for this situation.