UnZip/Zip problems on MacOS

Please upload a test module where this happens so we can have a look.

I created a small module with a single board using as background an image with an umlaut in the name. There is nothing else in the images folder, just that image (PNG). The module fails to load.

However, I also noticed that other files with an umlaut in the name did NOT crash Vassal, so I have to amend my previous statement. Just this one image is disliked by Vassal, for some reason. Just its presence in the Images folder crashes Vassal, even if it is not in use in the module anymore. I am not even sure it’s umlaut related at all.

Corrupted image or using wrong encoding in the filename or something? But the image itself looks fine when opened with any viewer.

Here is a Google Drive link to it (too big for the 256 KB forum limit):

drive.google.com/file/d/1esjZz0 … sp=sharing

Thus spake barbanera:

Corrupted image or using wrong encoding in the filename or something?
But the image itself looks fine when opened with any viewer.

Here is a Google Drive link to it (too big for the 256 KB forum limit):

drive.google.com/file/d/1esjZz0 … sp=sharing[1]

[1] drive.google.com/file/d/1esjZz0 … sp=sharing

You have a corrupted ZIP file there. Try recreating it and see if this
happens again.


J.

How do you mean corrupted? 7-Zip, for example, opens it without any warnings/errors.

As you can test yourself, If you remove that rogue image from the images folder (or replace it with another image) the module opens in Vassal.

However, when you put that image back Vassal won’t touch it with a barge pole: The socket over which the Module Manager communicates has had a fault. Please restart VASSAL. Not very helpful, if you added dozens of pictures in one go, for example.

I mean that Java’s ZipFile class throws the following error when reading the module:

java.util.zip.ZipException: invalid CEN header (bad entry name)

7-Zip, being a dedicated archive program, likely tries very hard to read corrupted or non-standard entries. Java doesn’t. You wouldn’t see this error in your errorLog. We don’t log it because we can’t tell programatically whether ZipExceptions are due to corrupt files, opening a non-module, or opening a file for import.

Indeed, but I cannot test myself whether you can create a module which triggers the problem reliably. Is this a fluke, or something you can make happen again?

I can’t replicate that myself. If I add the image to a module, or even just unzip and rezip your test module, it works fine.