I am running DirOpus Pro 11.13 X64 Build 5564.
I am trying to unzip the Raspberry Pi Debian Wheezy image, which is around 3.2G. I navigated to the source file on the NAS, and double clicked it to get the single file inside, which I then dragged to my desktop.
The source file is on my NAS which can handle gigabit ethernet speeds. I am extracting to my desktop. It has run now for over 2 hrs and it doesn't appear to have reached 75% yet O.o I have found DirOpus becoming unresponsive on occasion as I have been trying to check progress.
Task manger (Windows 8.1 pro 32G of RAM on an i4770k, fully patched) shows it using about 4-5G of RAM, peaking as high as 5.3 that I have seen and falling as low as about 2.4 that I have seen.
The display still shows it being stuck at 0% but the progress bar looks around 75%. snag.gy/D2Naz.jpg
Not sure what other info to offer to help diagnose the issue.
I think something is seriously wrong with this code.
Can't find how to edit... ZIP support obviously not SIP :-/
7-zip just extracted the file in about 15 seconds.
If you copy the zip to a local drive and extract from there do you still see the problem?
I copied the file from the NAS to a RAM disk in reasonable time (measured in seconds) and then opened it there and drug to desktop. Still ran incredibly slow... after a minute it appeared to have made it to maybe 5%. 7zip in still did the whole thing in like 20 seconds.
Is there somewhere we can get a copy of this zip?
Also, it may be worth checking with anti-virus scanning disabled in case the different ways the file is written to disk by different programs might be involved.
The ZIP file is here:
(The Raspberry Pi Download page raspberrypi.org/downloads/ , and choose the "Raspbian" download, if the above link should in any way fail.)
It could well be related to the anti-malware... I did note it using some CPU regularly... I will note that my CPU stays pegged at 100% with a bunch of processes running at the lowest priority... so if there is some sort of a interference in the communication between processes under those conditions then I could see where that would be an impact. The thing is, this is not a new condition for my PC, and I've not had this sort of issue ever before in the past.
If DirOpus is doing something like checkpointing the file regularly, and then anti-malware scans it, and then more checkpointing, more scanning and so on, this could explain the problem... but if that is the case then I strongly dislike this design... The file only needs to be scanned once at the end, when the complete thing is extracted.
I've tried here and was able to extract the archive normally. Opus and 7-Zip both extract it at the same speed.
Opus just opens the destination file handle and writes data into it, then closes it at the end.
it should not be closing & re-opening the file or anything like that. But some minor difference that should make no difference may be causing your antivirus scanner to behave differently, I don't know. (You can use Microsoft's Process Monitor tool to see exactly what is being done to the file to confirm it isn't being closed & re-opened.)
It's also possible a shell extension is being triggered in the destination directory, which is re-testing the file every time it is updated and using a lot of CPU in the process (as well as possibly flushing disk buffers).
What is the process using all the CPU when this is happening? Is it dopus.exe or something else?
I have the same issue with ALL zip files. Opus is very slow compared to 7Zip which can unpack super fast.
If all zip files, from all sources, are slow, I would suspect antivirus being more thorough with Opus than other software.
If it's only some zip files or ones made in certain ways, from certain sources, or containing certain types / numbers / sizes of files, then please give us some examples to look at.