Total data loss / corruption of all preferences

[mats.ahlgren@…]

My X-server crashed, presumably taking Jajuk down with it. However when I reopened Jajuk, the theme was different, and I got the "the last instance will save preferences" dialog. I select one of the options, but force-kill the app. I then look in .jajuk/conf.properties, and it seems to be the *default*.

Moreover, there are no conf.properties backups (like the collection.xml file; however the collection database was fine).

Setting severity to max.

It seems as if Jajuk should keep backups of the preferences, and not override the preferences if it detects corruption. If corruption is detected, it should:

1) make a temporary backup of the current conf

2) prompt the user: Please quit, or force-quit, any other instances of Jajuk that are running. [Ok] -- no other options

3) Say "Jajuk was not shut down cleanly. Reverting to last clean preference backup from [datetime]. Other corrupt preference files have been marked in ~/.jajuk and saved for you."

Logs reveal nothing interesting about how this could have happened. Dumb spam filter is preventing me from uploading log or inserting a URL to pastebin, but I can copy-paste into a comment if desired.

[bflorat]

After having check the code, I have no clue to understand how a preference lost could happen as we only actually write them to the conf.properties file when appling changes in the Preference view (or a few other place requiring a human "apply" action). Preferences are not stored at each session for instance like the collection is. It's why we didn't see the need to support preference backup.

@mats.ahlgren : are sure you didn't change of workspace (the .jajuk) directory after your crash. You may have several workspaces if you used released and test versions for instance because test versions's workspace is under ~/.jajuk_test_<version> direction. You may also have store your workspace on an external drive that wasn't anymore available after your reboot so jajuk uses a default worskspace (~/.jajuk) instead.

[mats.ahlgren@…]

Hello,

@bflorat:

Hmm, thank you for doing a code review.

I checked all the things you asked me to:

* changing workspace? -- I am fairly sure the workspace was the same, since Jajuk successfully read my collection.xml.

* possible ~/.jajuk_test_xxx folders? -- I do have a ~/.jajuk_test_1.8, but upon cursory inspection, the collection in there seems very small; it was unlike the one that was loaded when this bug happened. (Why might this exist? I recall trying to run some Jajuk versions via webstart, but they always failed to run, and I did not see any active java process. I do not recall when I did this, or if I did this around the same time the bug occurred.)

* external drives? -- I do not use any external drives.

Do you think the following hypothetical scenario could have happened?:

0) ~/.jajuk/conf.preferences file exists

[truncating so Akismet doesn't think my comment is spam]

[anonymous]

1) Jajuk fails to read or parse conf.preferences properly, and fails *silently* (perhaps it was corrupted when last written, or incompletely written, or there may be unescaped characters like if the user inputs \n or <br/> in a preference setting)

2) Jajuk assumes this is a first-time-run, and uses default preferences (despite the fact that collection.xml may exist)

3) Jajuk saves current preferences over conf.preferences (If the preferences file was unreadable, or corrupt, would a new one have been saved immediately -- or only after shutdown?)

[truncating due to spam filter]

[anonymous]

Whenever saving preferences:

testing to see if Akismet thinks this is spam

and

getPreferences() -- Checks if $JAJUK_DIR/conf.preferences exists on the filesystem. If so, attempts to read/parse it. If this fails, throw an alert and kill Jajuk, telling user to move $path_to_pref_file to another directory and file a bug. If $JAJUK_DIR/conf.preferences did not exist *and* we're in the first-time-run-wizard, then create new default preferences. [or whatever seems reasonable] etc.

getDefaultPreferences_unsafe() -- returns default preferences, perhaps useful for updating preference schemas

Also having a single preferences backup if it's possible to do with 3 lines of code.

(... or whatever seems reasonable in light of a reproducibility / code review / no other similar bug reports...)

(I do not think I hit "Apply", but it may have been possible; it was a while ago)

Without seeing the code, that's my best guess at a most-likely scenario. If you've gone through the code and don't think this (or anything else) is likely, I don't think there's much more than we can do before marking as "worksforme" (though I hate doing that) and hoping it happens to someone else who can give more insight. (Fortunately losing preferences in Jajuk isn't as bad as some other apps, or as losing the database.) If you go this route though, you might consider implementing a sanity-check that works like this:

[mats.ahlgren@…]

for pseudocode, please see [http]://pastebin.com/1bjt43Sw

[bflorat]

OK, I checked in a fix for this ticket. BTW, I told something wrong in my reply from the 13 may : the preferences are actually commited at each jajuk close so I have to agree that we need a more robust read/write system to handle the case you describe (even if it's probably very likely to occur).

Basically, I did something very similar from what you suggested :

• At commit, we begin to write down into a temp preference file, only after we override the final preference file -> so if the commit is corrupted, the original preference file is kept and used at next startup : we only loose the last session preferences changes.

• We now also try to load the newly created temporary preference file before overriding the final preference file so we make sure that it its content is not corrupted

• We also properly handle non-ascii characters in preferences (like templates preferences where use can type any text) using \uxxxx unicode format into the preference file.

I close this ticket, feel free to reopen if you can still experience preferences lost.