Cannot save changes to vmdx

I have been making modules for some time without issue. I upgraded to 3.7.1. Now I cannot save any vmdx files. It gives me the following error, on new files and old ones that I have not edited for months. only DEFLATED entries can have EXT descriptor
at java.base/
at java.base/
at VASSAL.launch.ModuleEditorWindow.lambda$save$0(
at VASSAL.launch.EditorWindow$7.ok(
at VASSAL.configure.ValidationReportDialog.lambda$createOkButton$1(
at java.desktop/javax.swing.AbstractButton.fireActionPerformed(
at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(
at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(
at java.desktop/javax.swing.DefaultButtonModel.setPressed(
at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(
at java.desktop/java.awt.Component.processMouseEvent(
at java.desktop/javax.swing.JComponent.processMouseEvent(
at java.desktop/java.awt.Component.processEvent(
at java.desktop/java.awt.Container.processEvent(
at java.desktop/java.awt.Component.dispatchEventImpl(
at java.desktop/java.awt.Container.dispatchEventImpl(
at java.desktop/java.awt.Component.dispatchEvent(
at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(
at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(
at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(
at java.desktop/java.awt.Container.dispatchEventImpl(
at java.desktop/java.awt.Window.dispatchEventImpl(
at java.desktop/java.awt.Component.dispatchEvent(
at java.desktop/java.awt.EventQueue.dispatchEventImpl(
at java.desktop/java.awt.EventQueue$
at java.desktop/java.awt.EventQueue$
at java.base/
at java.base/$JavaSecurityAccessImpl.doIntersectionPrivilege(
at java.base/$JavaSecurityAccessImpl.doIntersectionPrivilege(
at java.desktop/java.awt.EventQueue$
at java.desktop/java.awt.EventQueue$
at java.base/
at java.base/$JavaSecurityAccessImpl.doIntersectionPrivilege(
at java.desktop/java.awt.EventQueue.dispatchEvent(
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(
at java.desktop/java.awt.EventDispatchThread.pumpEvents(
at java.desktop/java.awt.EventDispatchThread.pumpEvents(
at java.desktop/

We need to see the rest of the errorLog to comment on what might be wrong.

NVM found it Attaching now. Newbie here. Log is too long to go into a post and I cannot figure out how to attach a file

Maybe try a paste bin and provide a link?

I put it on my site.

It looks like you’re trying to edit WW2AS-JavaSea.vmod, not an extension. Can we see that file?

You are correct I am trying to edit the module not the extension. I can seid it to you if you give me a private address to send the link. I can’t post it here till Avalance Press announces the availability.

OK was going to send you a link to download, but at this time the error is gone. Don’t know if it was me or the app or the environment but I should cancel this at this time and re-open if necessary.

THANK YOU SO MUCH for helping. I really appreciate that and this community and environment for letting me create.

1 Like

Send me a private message with a link to it.

Last question how do I send you a private message?

Click on my avatar. You’ll see a “Message” button.

E.g., this is what I see when I click yours:

Sadly, I do not. Just the posts on topic

OK that is fixed too, Thank you.

You might not be able to send messages yet due to being a new user. I will send you a message—perhaps you can reply to that.

Yes, I can now. I am new so that makes sense. I have to go to my paying job now and I think it is working so I will contact you on this if it re-occures

It is broken again. Sending a private message with locations of files

I think you’re seeing the effect of this Java bug:

Given that this bug was filed in 2015, I would be surprised if it’s ever fixed.

The file in the module triggering the bug I believe is this one:

-rwxr-xr-x  1.0 unx        0 bX stor 23-May-10 14:20 images/Player Info Markers

That’s output produced by the zipinfo command run on the module. What’s it’s showing is that images/Player Info Markers is a file of zero size.

When I run zipfnfo -v to get additional information, I see the following for that file:

Central directory entry #201:

  There are an extra 8 bytes preceding this file.

  images/Player Info Markers

  offset of local header from start of archive:   25278607
                                                  (000000000181B88Fh) bytes
  file system or operating system of origin:      Unix
  version of encoding software:                   1.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   1.0
  compression method:                             none (stored)
  file security status:                           not encrypted
  extended local header:                          yes
  file last modified on (DOS date/time):          2023 May 10 06:20:54
  file last modified on (UT extra field modtime): 2023 May 10 14:20:54 local
  file last modified on (UT extra field modtime): 2023 May 10 13:20:54 UTC
  32-bit CRC value (hex):                         00000000
  compressed size:                                0 bytes
  uncompressed size:                              0 bytes
  length of filename:                             26 characters
  length of extra field:                          32 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  Unix file attributes (100755 octal):            -rwxr-xr-x
  MS-DOS file attributes (00 hex):                none

  The central-directory extra field contains:
  - A subfield with ID 0x5455 (universal time) and 13 data bytes.
    The local extra field has UTC/GMT modification/access/creation times.
  - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
    01 04 f6 01 00 00 04 14 00 00 00.

  There is no file comment.

You can see that the compression method is “stored” and the file has an extended local header, which is exactly what triggers the bug.


I think the only available workaround will be to avoid writing empty image files into the module.

Thank you @uckelman That was the issue. I do not know how that file was written but it showed up in the finder of the images folder with zero bytes so it was easy to find. I deleted and recompressed and it opens and saves like a charm now.

Wish I could buy you a beer. Thank you especially for the great explanation with all the detail.

1 Like