Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Over years, this happened to me quite a few times and
Tsk tsk, didn't report it 😉
It's true that I haven't seen it for a long time but I suspect it's because file systems got better rather than fixing something on the Geany side.
Its true that Geany improved by saving settings more often, (not sure it it is yet every change but getting close) and it became more reliable so crashes during saving happened less (debugging Geany or plugin changes excepted). And using a better config saving method will improve again, but in the end saving can always be interrupted by internal causes, or external causes.
Geany really is the only application where I experienced this and it's kind of embarrassing.
Similar to my report of #3733 where Vscode survived a system failure with all settings and modified buffers intact and Geany lost all buffer modifications. So I can now understand why users shutdown or logout with the app still open and expect things to come back, it "just happens" with chromium/electron based apps so we get regular issues about it.
Thats why I keep plugging it, it would be a tiny @techee change (<30000 lines ;-) to save buffers and their associated document settings in the config directory, it could even be in save actions plugin.
Anyway back to the PR.
My suggestion is that all keyfiles should be written with g_replace_contents() because it works in all cases, that is why it is the default for data file saving. As it is an atomic (rename) save with metadata copy if possible, the window for losing all settings gets very small (but not zero), but it falls back to the truncate and write over if the metadata copy or the rename fails. Effectively it does both the other methods so they are not needed any more1.
And as an aside I suspect it will prevent rooters ending up with keyfiles owned by root since g_replace_contents() copies old metadata to the new file before renaming, meaning it should end up still being owned by the user. (analysis, subject to testing :-).
and its because of the fallback to truncate and overwrite that it has the "unsafe" in the setting that selects it for saving document files, in that case its no more safe than that option. Annoyingly it makes a backup of the file in the truncate case, but it never uses that backup in the case of failure (I just checked the GIO bug is still open). Saving document files still needs the options for the reasons explained in my file saving thesis. ↩
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.