UnZip/Zip problems on MacOS

[uckelman]

Thus spake marktb1961:
>
> Yes I have a retina display. I hadn't noticed a problem before and now I
> look at it, the dragged images are 1:1 in v3.4.6 (compared to the pieces
> on the board). In the snapshot, they look like 2x size.

I was wondering if that would happen. Apparently this fix should be
applied to Windows only. Thanks for testing.

--
J.

[jrwatts]

Thus spake jrwatts:
>
> This was not my experience with 3.4.5 (on Linux, Java 11.0.8 ) last
> week; I was replacing 5 images with new versions, and when I tried to do
> it with the editor, the old images stayed in place. I had to use an
> external archive program to replace the images.

Is this something you can reproduce reliably? What are the exact steps
you took?

--
J.

I can't seem to reproduce it at all with 3.4.6. I suspect I simply forgot I needed to completely close out of the module and reload it to get the new images to appear last time.

(Apologies to Mark for hijacking his thread!)

[uckelman]

Also, do I remember correctly that one of you reporting this is using a Mac with a Retina display? If so, there's a second thing I'd appreciate it if you'd check in this build. I suspect that in 3.3 and previous 3.4 builds, the image you were seeing
when dragging pieces was half-size, and in this build that should be back to normal. Is it?
)

Yes I have a retina display. I hadn't noticed a problem before and now I look at it, the dragged images are 1:1 in v3.4.6 (compared to the pieces on the board). In the snapshot, they look like 2x size.

I will test the zip issue in the morning.

Mark

Try VASSAL-3.4.7-SNAPSHOT-6733719d0. That should put the drag image back to normal for you on a Mac. (The fix needed to be applied to Windows only, apparently.)

[marktb1961]

Try VASSAL-3.4.7-SNAPSHOT-6733719d0. That should put the drag image back to normal for you on a Mac. (The fix needed to be applied to Windows only, apparently.)

Yes, back to normal.

[barbanera]

I think I have a report related to this. Image files with umlauts, for example, break Vassal: it will say it's not a Vassal module and fail to load it. And I mean just having them in the "images" folder, even if not used in the buildfile.

I had been editing the buildfile for a very quick image name fix (unrelated to the umlaut) - stupidly forgetting to take a backup first - then reloaded the images folder from a backup, after doing the same edits on the filenames, and started getting the errors. I panicked for half an hour thinking I had lost 3 hours of work breaking the buildfile somehow, before noticing that I had copied along an older rogue image with the umlaut in the filename.

Perhaps some hint that there is an issue with the images folder, rather than the buildfile, could be given in a future release?

This was both with 3.4.12 and 3.5.0 beta 2. Running Windows.

[uckelman]

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

[barbanera]

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):

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

[uckelman]

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):
>
> https://drive.google.com/file/d/1esjZz0 ... sp=sharing[1]
>
> [1] https://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.

[barbanera]

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.

[uckelman]

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

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.

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.

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?

However, when you put that image back Vassal won't touch it with a barge pole:

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.