Preferences file problems

Users—especially, though not exclusively, users running Windows—have reported assorted problems every since I can remember with the Preferences file becoming unwritable. Recently, we’ve had a substantial increase in these reports, for reasons we’ve yet to determine. There were a few changes regarding preferences in 3.2.7, but my impression is that we’ve only had more reports of problems since 3.2.7, not reports of any new kinds of problems.

My guess is that we have at least two things wrong: I think we’re seeing contention between the Module Manager and the Player/Editor when the former is trying to write and the latter is trying to read the Preferences file (on Windows), and that perhaps the fix for Bug 10179 is bad. But I don’t have conclusive evidence for this yet, and it’s generally been very difficult to extract information from people reporting such problems.

Our inability to track down a cause or causes so far has me wondering if there’s a way we can sidestep this entirely. A lot of the complexity of the code for reading and writing the Preferences file stems from (1) that it’s a ZIP file and Java provides no means of updating ZIP files in-place, and (2) that different processes need to update entries in the Preferences file, and might try to do so concurrently. I don’t know why the Preferences file was originally made a ZIP containing global entry and an entry for each module instead of a bunch of individual files—but I’m pretty sure the reason wasn’t to conserve disk space. My Preferences file has entries for 120 modules, which I would guess is way above average, but the uncompressed data comes to a negligible 429KB.

So, what if we switched from a single Preferences file which is a ZIP archive to a directory containing one file per module? I suspect this would eliminate the problems users have reported with the Preferences file being unwritable, at least on Windows, as it would mean that the Module Manager would be writing its settings to a file which the Player and Editor never touch.

Thoughts?

Sounds eminently sensible to me

Try 3.2.8-svn8790: vassalengine.sourceforge.net/builds/

This build contains some uncommitted changes to the way the prefs are stored, namely:

  • Preferences are now stored under the prefs directory.
  • Each module (and the global prefs) gets its own prefs file.
  • I came up with a name-mangling scheme to ensure that we don’t try writing files with names which aren’t valid filenames, so the filenames are not always literally the name of the module, but will always be unique.
  • The old Preferences file will be converted to this scheme the first time you run 3.2.8 or later.

Try this out.

Hmmm…

What happens if you run 3.2.8, and then 3.1.20? I assume the old zip is still there for 3.1 to find and access?

What happens if you do that and then run 3.2.8 again? Will it see the new directory, and not re-translate the zip file just modified by 3.1?

Thus spake Rindis:

Hmmm…

What happens if you run 3.2.8, and then 3.1.20? I assume the old zip is
still there for 3.1 to find and access?

3.2.8 doesn’t write to the old Preferences file at all.

What happens if you do that and then run 3.2.8 again? Will it see the
new directory, and not re-translate the zip file just modified by 3.1?

3.2.8 converts the old Preferences file to a new prefs directory if and
only if there is not already a prefs directory.


J.