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?