Module always thinks it's not writeable

Have any of you guys ever encountered a problem where a module constantly thinks something still has it open (or whatever) so that it isn’t writeable? (I think really, the old version can’t be deleted so that it can rename in the new version)?

A month or so ago I started on a module for the new COIN game coming out soon, and (perhaps a mistake) I just started with what they’d been using for playtest, thinking that would be a coherent starting point to work from. And it was… except that I keep having this problem.

Specific details:

  • If I just go into Edit (only) and never actually launch the module, I can still save fine.
  • But once I launch the module (e.g. “start new game”), from that point on I can no longer Save the module – it ends up having a write-error. (My choice is then either to Save As… and rename it later, or to exit and find the tmpXXXXX.zip file that just got created and rename it in myself)
  • Nothing else (meaning no other process) actually has the module open for read or write – once I exit the editing session, I can freely rename/delete/whatever the module from Windows or any other app. (So it’s not the classic problem of “whoops I left 7 Zip open in the file” or whatever)

Just checking to see if anyone else has ever run into this, in case you might know what “flavor” of bad thing is going on the module somewhere creating this problem. I don’t really have much going as far as custom classes in the module – just garden variety Chatter stuff that doesn’t give me problems in any other module.

It’s obviously workable-aroundable, but VERY frustrating.

Brian

Short answer - No idea and I generally do not have this problem unless I do the leave open in 7zip thing.

Long answer - We used to get this problem all the time for no apparent reason and it mostly went away when Joel did a bunch of work on the zip archive handling. I think there where file handles not being closed properly.

I say generally and mostly because I still occasionally get an unexplained case of a module not wanting to save and having to do a ‘save As’ or chase the tmp file. I suspect there is still a bug there, just rarely happens to me.

(Here is a condensed version of the error log I get, with the boring parts of the stack dump left out)

java.io.IOException: Unable to overwrite C:\Users\Brian Reynolds\Documents\Gaming & German Game Rules\Vassal\All_Bridges_Burning_1.0.vmod: Data written to C:\Users\Brian Reynolds\Documents\Gaming & German Game Rules\Vassal\tmp593797397428243503.zip instead.
at VASSAL.tools.io.ZipArchive.writeToDisk(ZipArchive.java:510)
at VASSAL.tools.io.ZipArchive.flush(ZipArchive.java:382)
at VASSAL.tools.ArchiveWriter.write(ArchiveWriter.java:240)
at VASSAL.tools.ArchiveWriter.save(ArchiveWriter.java:231)
at VASSAL.build.GameModule.save(GameModule.java:1010)
at VASSAL.build.GameModule.save(GameModule.java:989)

at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.io.IOException: Unable to delete file: C:\Users\Brian Reynolds\Documents\Gaming & German Game Rules\Vassal\All_Bridges_Burning_1.0.vmod
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2106)
at VASSAL.tools.io.ZipArchive.writeToDisk(ZipArchive.java:492)
… 48 more

Well if somebody wants a 100% repro case, I know “just the module” :slight_smile:

Are there any other errors or weird messages reported further back in the log file?

The other weird module saving bug I get occasionally is that all of the DTM stamps on all files in the module get set to 0. This causes the module to re-tile every time it opens. Only solution is to extract all the files, use a 3rd party tool to reset the DTM stamps and zip it back up.

Nope, that’s the top and bottom of the log, with just some stack dump pulled out of the middle for brevity.

Now that I’m thinking about it, I can also reproduce this problem with any module if I make a save file (for a scenario start entry), then add the save to the scenario list, then try to save the module. To be able to save successfully after adding/changing/updating a scenario save, I only succeed I’f I come in “completely clean” - save already made in a prior session, and I go straight to scenarios menu, make my change, and save.

I suppose I should write up an official bug. It does sound like the “hours of misery tracing through code” type of bug that Flintb was hoping for :slight_smile:

Brian

Yes please, write it up. It is very annoying and confusing for new users when it happens.

Now that you mention it, I seem to remember having had this problem triggered by adding html help files to a module. I got in the habit of updating them by 7zip instead.

K will write it up tomorrow

Is now bug 13014. Probably in moderation.

Is bug moderation a Joel-only thing?

vassalengine.org/tracker/sho … i?id=13014

Brian

This happens to me from time to time, usually with OpenOffice where I can’t open the app, but sometimes with Vassal as you described. In Windows, I open the task manager (right click the bottom bar) and look through there. I often will find a process that should have died but is still present (with no visible evidence) and has the file I want open. I kill it, and I’m good to go. The state usually happens with an obvious app crash, but sometimes things don’t go completely away beneath the surface. Next time it happens, check your task manager or equivalent. Maybe you will see something.

I’m definitely familiar with the occasional app-stays-open-after-I-close-it type scenarios, but this is a 100%-repro of the editor/game session itself being the thing that is holding the file open against itself.

Happens to me too. I started seeing this when I installed 3.3.0 beta, and started using some cattlesquat’s custom code in my module so I thought it had to do with one of this. But then I created another test module with same custom code, and this error didn’t appear.

It happens also whenever I try to record a log file.

Thus spake cemoreno:

Happens to me too. I started seeing this when I installed 3.3.0 beta,
and started using some cattlesquat’s custom code in my module so I
thought it had to do with one of this. But then I created another test
module with same custom code, and this error didn’t appear.

It happens also whenever I try to record a log file.

On what OS?


J.

This might be related to this bug or might not, but the closeQuietly() is no good, we should either be using try-with-resources or call close() manually and log possible exceptions.

Windows in particular has a long history of leaving files open for days, weeks and even months, for no apparent reason.

W10. I write the module to a OneDrive folder on a compressed volume, in case that might make a difference.

Flintb - this is filed as Bug 13014 ( vassalengine.org/tracker/sho … i?id=13014 ) with some repro case examples if you get in a having-a-look mood.

Thus spake Flint1b:

[This message has been edited.]

This might be related to this bug or might not, but the closeQuietly()
is no good, we should either be using try-with-resources or call close()
manually and log possible exceptions.

Windows in particular has a long history of leaving files open for days,
weeks and even months, for no apparent reason.

If you want to kill the rest of the uses of closeQuietly(), go for it.
Just note that a lot of the remaining ones are tricky.


J.