Flatpak Evolution forgot it settings (again!)

[mmarjano]

Hello,

I'm using flatpak version of Evolution because the version in my distro's repositories is too old, contains bugs and has a missing feature that I need. I don't care much for the sandboxing nonsense, I simply want it to work without tinkering.

That being said, every now and then it forces me to tinker with it because after updates it sometime forgets it settings. For instance I have set these options:

• preview - vertical view
• HTML messages
• inline reply and forward
• reply above email
• signature above email
• no -- signature delimiter

Now most of these I can go and change again for nth time, but for instance signature delimiter has no setting in the GUI, so It's another pain point. I'd much rather prefer for Evolution not to decide to nuke my settings and force me to redo them every so often.

Thanks!

[mcrha]

Hi, the update should not cause settings reset, definitely not intentionally.

I see the flatpak manifest contains "--metadata=X-DConf=migrate-path=/org/gnome/evolution/", which the upstream manifest does not have. Maybe it's causing the problem, the flatpak tries to sync the settings from the host machine to the sandbox and overrides your in-flatpak settings, because the host machine either has Evolution still installed or there is some left-over settings in the DConf for the Evolution, which contains the data.

Does dconf dump /org/gnome/evolution/ return anything for you, when you run it on the host machine?

[mcrha]

I tried to reproduce this by setting Edit->Preferences->Composer Preferences->Replies and Forwards section in the flatpak and on the host into different values and the first downgrading the flatpak app to a previous version (flatpak update --commit 4e59d6f9f4201780488fbb09917677fcd9afd6d569327df0d46bbc5bc41b9b60 org.gnome.Evolution) and then back to the latest, both once when the flatpak had left running the background evolution-data-server processes (closing the Evolution window does not close the flatpak sandbox) and also when I stopped the process before the flatpak update (flatpak kill org.gnome.Evolution), and it did not reproduce the problem in both cases.

Maybe, is there any auto-cleanup of the ~/.var/app/ or ~/.config/ or any such directory in your system set?

It seems the sandbox saves the GSettings into the ~/.var/app/org.gnome.Evolution/config/glib-2.0/settings/keyfile file by default.

[mcrha]

It seems the sandbox saves the GSettings into the ~/.var/app/org.gnome.Evolution/config/glib-2.0/settings/keyfile file by default.

I just verified the migration with the settings from the host system runs only if the keyfile file does not exist. At least with flatpak-1.15.8

[mmarjano]

Does dconf dump /org/gnome/evolution/ return anything for you, when you run it on the host machine?

It returns quite a lot but by skimming through the returned output, I can see that those are the settings of old Evolution installed on host machine, and they're not different from the state I like. So even if those were copied to the flatpak, it would have been fine.

Also, if it's not clear from my previous message, this doesn't happen during every update. It happened once or twice before, and I've had it installed as a flatpak probably close to a year. Reading my previous message now, I realize that I gave out impression that this happens often, but my wording at that time came out of the fact that I was annoyed :)

Also, I don't know if this is important, but I have previously enabled "All user files" setting through Flatseal, so that part is different than defaults.

Since this happened I've re-applied my desired settings, so it works now as expected, but I'm willing to provide any additional info or command outputs if it will help confirm this issue and detect the cause.

[mcrha]

In that case there probably happened something to that ~/.var/app/org.gnome.Evolution/config/glib-2.0/settings/keyfile file. Whether it's still at that place when you enabled "All user files" I do not know, but I suppose it is.

Could you make a copy of that file and when the issue happens, compare the copy with the current file, both with the content and with the file attributes, like the last modification time? That won't show why it had been changes, it'll only show it had been. I'm afraid there is nothing usable to track certain file changes, to see which process and when touched it; at least I'm not aware of anything for it.

As you have the host system settings similar to what you want, I guess we can safely ignore the migration code.

[mmarjano]

I've backed up my current file, and if this happens again I'll update this issue with a diff. Thank you!