Problems creating zip files containing empty folders

Help & Support
1

I've already reported this via the official support form, but I wondered whether anyone else can confirm this behavior.

I seem to have discovered a problem in creating zip files with the Opus 'Add to Zip' function.

What I'm about to describe here applies when actually creating a new zip file and when and only when a password is specified for the zip file.

I've made no attempt to discover what happens if files are being added to an existing zip file, but I can say that this problem does not exist if no password is specified for the zip file.

If more than one folder is selected for inclusion in the new zip file and one of these folders or a subfolder is empty, the resulting zip file is unusable.

Trying to extract the contents of the zip file in Opus results in nothing happening.

Trying to extract the contents of the file in PowerDesk results in a message that access to the file is denied.

Trying to delete the file in either Opus or PowerDesk results in a message that the file is in use by another program.

These symptoms exist until Opus (not just the lister) is terminated.

If Opus is terminated and restarted, attempting to extract the contents of the zip file in Opus still does nothing.

Attempting to extract in PowerDesk now produces a message 'Error in ... archive directory'.

After the termination of Opus, the bad zip file can be deleted in either Opus or PowerDesk.

Also worth noting is that if one single empty folder is selected for inclusion in the zip file these synptoms do not occur. The empty folder has to be one of multiple files or folders selected to cause the described symptoms.

I don't know if this is a problem in Opus or some weird problem only on my system. I'd think it possibly some problem inherent in zip files, but if I do the same zipping operation in PowerDesk, the contents of the resulting file can be extracted with either PowerDesk or Opus.

2

I have already logged one .zip issue (with empty folders) and I have at least one more I'm still analyzing (adding items to an already existing zip).

Please post the specific command syntax you are using here in a code box so I can try to recreate your results.

3

Based solely upon your description above, it sounds like Opus never actually completes creating the .zip archive, and has entered an endless loop. The archive may appear, but it's still being accessed by Opus. This is why you cannot delete the file until you terminate Opus. It may also be why you cannot open the archive in any application (it is corrupted because it was never completely written).

I seem to remember seeing something like this a few times, but it's been awhile.

4

Yes, intuitively, I also suspect that Opus has not finished with the file and may be in a loop.

Command syntax? Either I don't understand or I'm not using a command.

The error is pretty simple to reproduce.

Just create two folders, one empty, one containing a file.

Select both folders.

Right click the selection.

From the context menu choose "Add To Zip...".

From the "Add to ZIP File" dialog, specify a new zip file, check the Password option, and enter some password.

This should result in the situation, I've described.

It may or may not be relevant that the specified zip file not exist, but that's the only condition I've encountered or tested.

5

Yup, I can confirmed this.

Good catch rcoleman.

6

Not a lot of analysis here folks:)

This seems to be some issue with the DynaZip library and BATCH add options and the empty folder. Unfortunately it is a known issue that the BATCH functions for the zip library can give undesired and unwanted results at times.

Go to Preferences - Zip - Settings - and turn off "Use Batch Add".

We've added it to the anomaly list to look into for a future version.

7

At first, I couldn't reproduce this behavior, but I can now. There is a workaround for this behavior. Disable the option below in Preferences - Zip - Settings:

Use batch add (uses batch mode when copying into Zip files).

With the option above disabled, I got the desired results: all selected folders (empty or otherwise) and files were added to the resulting .zip archive, and it was password protected.

If you read the contextual help, and the Preferences - Zip section of the Opus 8 user manual, you'll see that Opus Zip batch mode is prone to error, which is why it is an option. It's faster, but less stable.

8

EDIT: typing the same time as Greg

@Greg I know that "not a lot of analysis" comment wasn't aimed at me! :wink:

9

Actually...:slight_smile: You may say that but I could not possibly comment!

10

Well, I agree that turning off batch probably solves the problem. I haven't analyzed the contents of the created zip file in great detail, but at least the zipping completes and the file can be unzipped (extracted).

The problem (maybe problem isn't the right word) is that zipping without the batch option isn't only slower than with the batch option, it's dramatically slower than zipping with other programs.

I have a collection of files which zips (without batch) in 3.5 minutes in Opus, but 17 seconds in PowerDesk.

I'm currently in an evaluation period for Opus. I may well decide to keep it for most routine file management operations, but I think I'll have to keep PowerDesk for some zipping operations due to the tremendous difference in time taken.

11

I believe we have a fix for this problem (that doesn't require turning batch mode off) - we will hopefully be releasing it in the next week or so.

12

I've continued to experiment with this.

It appears that zipping with Opus under any circumstances is somewhat slower than doing so with PowerDesk, but I think the huge discrepancies are related to scanning by Norton AntiVirus Auto Protect.

If I turn Auto Protect off and zip with batch mode off in Opus, it still takes longer than with PowerDesk, but not rdiculously longer.

So one could perhaps blame Norton AntiVirus rather than Opus, but the question still remains why is PowerDesk considerably faster than Opus with Auto Protect enabled.

This is just speculation which could well be incorrect, but I suspect that at least in non-batch mode, Opus is adding files to the zip file in such a way that the zip file is scanned by Norton for each added file and that PowerDesk is somehow creating the zip file in a way that causes only one scan after the zip file is comlplete.

13

Just to provide as much information as possible, even with batch mode on (and Norton Auto Protect on), zipping in Opus still takes "too long" (very precise term, of course) :slight_smile: , but in this case the "excessive time" occurs after the operation is "complete".

That is, the "Zipping - Directory Opus" window runs up to 100% fairly speedily and then sits there, and sits there, and sits there ...

It appears that, at least in batch mode, Opus uses a randomly named temporary file at the same destination as the zip file being created. It also appears that this temp file and/or the zip file are repeatedly scanned by Norton after the "100% complete" has been reached.

If I watch the location of the zip file, I can see the temp file coming and going, changing size, and so forth.

I also sometimes get alerts from Norton that Directory Opus is waiting for a scan of (zip file) and/or (temp file). Why I sometimes get these alerts and sometimes not, I don't know.

14

That's exactly the difference between batch mode and non-batch mode, as I understand them. Batch mode adds all files as part of one operation while non-batch mode adds one file at a time, closing the archive between each addition.

I haven't used Norton for a while (switched to NOD32) so I can't remember whether it has options that would help here without being a security risk but there might be a setting or two which would help.

Or just use batch mode and wait for the fix. Non-batch mode is always going to be slower anyway.

You can also integrate 3rd party zip tools into Opus either via toolbar buttons or context menus, if you want.

15

The problem is that using batch mode often causes errors (which is why this thread started). Many of these are known issues. So his "choice" (within Opus options) boils down to "slow" or "error-prone".

Jon and Greg know there issues with Zip. And fairly soon I'm going to be submitting some more (I'm still analyzing a couple).

16

I wouldn't mind the "choice" of "slow" or "error-prone", but the choice of "error-prone" or "ridiculously slow" is another matter.

I don't mean to be obnoxious here, but I want to make it clear how "bad" this is.

I have files that I routinely "zip up" for backup purposes. Using PowerDesk (with Norton Auto Protect on), I can do this in approximately 1.5 minutes.

I just tried the same thing with Opus (batch off) and finally aborted the operation at 78% after 2 hours and 37 seconds!

Granted, for this operation I could disable Norton Auto Protect which makes the elapsed time tolerable, but it's still 4.5 minutes vs 1.5 minutes and in Power Desk, I don't have to think about Norton.

It's really convenient to have zipping built in to one's primary file manager, but all in all, I have to consider zipping in Opus not a viable option at this point.

17

Well you have the option to turn off Norton - if you decide not to do that it's up to you.

The batch mode is not that error prone - as I said, we'll have a fix for this bug with empty folders (which only occurs when you are encrypting the archive) soon. Other than this batch mode generally works fine - I use it all the time.

18

I've found another oddity in Zip processing, but have started a new topic "Inconsistent behavior when Zipping System Volume Information" since the issue is not really related to the title of this topic.

19

I confirm that 8.2.2.5 seems to correct the problem of a Zip file not being correctly created when using batch mode and specifying a password for the file if the things being put in the file include an empty folder.

I still have some strange behavior creating zip files, but I'm beginning to think this behavior is related to specific files and/or circumstances which I don't yet understand. If I isolate the circumstances, I'll bring the matter up somewhere else because it doesn't have anything to do with empty folders or passwords.