Bug while creating ZIP files

Hi!

I'm using DOpus Version 9.1.1.5 and it still seems to have the "old bug", which accompanies my "working life" since version 8.x:

When I try to create a ZIP file of a large (> 100 MB ) folder, DOpus hangs in an endless loop. Although the ZIP file is already created, it creates a temporaray file over and over again. You cannot cancel this process, so you have to kill Dopus via the WinXP taskmanager.

According to the release notes, this bug was fixed a long time ago!

Can anybody tell me, why the bug still seems to be alive in my DOpus version? Could it be, that for some reason the "ZIP DLL" is not updated on my PC?

Thanks for your help!

Best regards,
Sven

How long did you wait for it to finish? It's normal for the Zip library that Opus 9 uses to do what you describe in some situations, unless it's doing it forever.

It may also be worth temporarily disabling any real-time anti-virus you have in case that is interfering. If it detects the temp files as zip archives it may be doing a full scan of each one which could slow things down a lot.

You may also want to try toggling the "batch" options in Preferences -> ZIP Files to see if that makes any difference.

It's been quite a while. I don't remember all the details, but I had similar sounding problems when I first started using Opus. As a newcomer, I may not have been as persistent as I might be now, but I couldn't convince anybody that there was a problem so I stopped using Opus integrated zip support except for occasionally viewing the contents of zip files. I switched to using 7-Zip for creating and extracting from zip files.

I'm now happy with my 7-Zip usage, so while I express moral support for the original poster, I'm not sure I now want to spend the time and effort necessary to try to prove there is a problem.

Well, I waited over 10 minutes! Please note, that the finished .zip-file lies in the folder, but you cannot access it.

Everything starts with a temporary file being created, which is renamed to the final zip file after everything is in it. Then a new temporary file is created with a new name. Size is getting bigger and bigger, till the size of the finished ZIP file is reached. The temporary file gets renamed (or deleted, I don't know, at least it disappears) and a new temporary file is created and now its getting bigger anf bigger, till... and so on.

The final ZIP file (which is accessible after killed Dopus) seems to contain all data and its consistent.

In my company, I'm not able to disable the anti-virus (I'm using Trend Micro OfficeScan), so this is not an option.

I'll try toggling the ZIP batch option tomorrow and see if it helps!

Thank you!

I have just tried to re-create your scenario. I selected a folder containing over 19000 files and 345MB in size, right clicked on the folder, selected add to zip and Opus created a zip file in less than 3 minutes. It sounds to me like Leo could be right with regards to anti-virus software. I never use AV software as they are such a resource hog and seem to cause more trouble than they're worth. I prefer to run my web-browser inside a sandbox so that anything nasty can't infect the rest of the system.

Try disabling any AV software and see what happens.

FWIW I'm not saying that anti-virus software is bad. I run NOD32 myself.

A/V software can be behind strange things happening, though, since it inserts itself into almost every file operation. So it's usually a good idea to rule it out before investigating further especially when something only happens for some people.

Well, sorry for the long delay, but I tried a lot:

I have

a. a nearly clean & new installation of Windows XP
b. installed Directory Opus 9.1.3.0.3449.x86 (german version)
c. not changed the DOpus configuration (only confirmed the dialog right after the installation)
d. deactivated my virus app (Avira AntiVir)
e. seen this bug on two totally different computers

I zipped a distribution of MinGW and DOpus is busy a really long time (3min), although the archive is created yet and has a size of 42,2 MB.

BUT: After creating a random file approx. 30 times, it ends now!

Can someone tell me, why DOpus is creating random files with a high CPU load (while showing 100% progress and not handling the cancel-button), although the archive is already there? Is DOpus optimizing the archive? Or is this an unwanted "feature"?

I can provide you with the MinGW archive (packed by DOpus). You can extract it to your HD and let DOpus zip it again. You should get the same
result hopefully :slight_smile:)

Thanks for your help!

Best regards,
Sven

At a guess it's because there are thousands of small files, but without seeing the archive it's just a guess.

42MB is too large to attach to a forum post but if you can send it some other way (e.g. RapidShare) or just tell us where to get the source files (presumably one of these?) then I'll see if I can reproduce the problem.

I uploaded the archive to my website. Here ist the link:

http://www.mikrosol.de/MinGW.zip

I'm really curious, if you can reproduce this behaviour!

I can't reproduce the problem, sorry.

A screenshot of my Zip settings is below in case any are different and you want to try using the same settings that work for me.

Question: If you copy the zip file, does that also take a long time? If so then it's almost certainly due to an anti-virus scanner looking inside the zip archive after it is created.


Hi,

i just tried using the provided MinGW.zip. Here are my observations

  • DOpus shows a considerable time (2-3 minutes) the file progress dialog at 0% with 90-100% CPU load for either extracting/zipping the archive/files
  • Then DOpus will quickly extract the archive (2 minutes)
  • DOpus will also quickly zip the files BUT with 100% file progress temporary files (name TT304840 or similar) are getting created over and over again with varying sizes from 0 bytes to the size of the finished archive. The archive is already visible but the file progrss dialog stays at 100% for 5-10 minutes. The CPU load is at ~20%.
  • Disabling AV and windows search/indexing will speed up the extracting/zipping by factor 10.

Are your zip settings the same as shown in the screenshot above?
Also are you using 32 or 64 bit Opus?

Which AV tool is that with?

Which version of Windows or Windows Search?

I had exactly the same problem, it only happened zipping files over 100MB and caused Opus to get "stuck" at the end of the zipping and killing Opus was the only way to get out of it.

When it happened i couldn't find any widespread reports of it on the forum, so just figured it was an isolated bug on my system.

It's no biggie, when i compress +100MB files it's just personal backups for my external HD in case of a system failure so i've been using WinRar for that as format doesn't matter.

I have NIS2009 installed, how about you OP?

McAfee VirusScan 13.3

WinXP Pro SP3 and its indexing service

[quote="jon"]Also are you using 32 or 64 bit Opus?
[/quote]

WinXP 32bit


The obvious difference is the 'Use working folder for removable media only' option. Try turning that on.

I saw the difference but from the manual I judged that it's only relevant for removable drives. Did I misunderstood the help.

Nevertheless I turned the option on, but I didn't notice a major difference.

I'm really glad, that some other persons are having the same problem.

@leo: I tried exactly your ZIP settings and the effect is the same: Problem is still there. My anti-virus scanner was deactivated, so it's not causing the strange effect. If I copy the ZIP file, everything is fine and fast. No problem then, even if the AV scanner is active.

@jon: "Use working folder for removable media only" doesn't make any difference here either.

I can confirm this problem, i tried to ZIP a few 100 MBs & the process went almost immediately into a sort of loop, no progress bar & the CPU-usage went up to full.

Someone in the german Opus forums mentioned, that trying to pack multi-levelled (lots of subfolders) data will lead to a more pronounced bouncing between 100% & lower percentages compared to if the same data was packed from a flat hierarchy. Maybe that´s a hint?

Another idea was, maybe sometimes the size of the standard windows temp folder might not be sufficient, leading to constant swapping or something like that.

This problem is still active in Version 9.5.0.3565.x86, which is very annoying and it disables me to do my every day work, because I always have to kill the DOpus task.

It would be very nice, if the GPSoft team could analyse this bug!