Description

I am working on ticket https://dev.haiku-os.org/ticket/5026, which involves pulling Deskbar preference settings and using them to limit "recent folders" on Backgrounds preflet. During my development process I noticed that the Deskbar settings file isn't properly created, but yet the Deskbar settings were still persisting. Then I realized that because the Deskbar is always running, the settings are being changed in memory but when you reboot Haiku the preferences return to the defaults because they cannot be loaded from the settings file (since it was never created).

I'm planning to fix this issue as part of #5026 since without the fix I can't get Backgrounds working the way the ticket intended, but I wanted to record this as an issue for tracking purposes.

Janus you are correct. I deleted the settings file and that lead to this scenario. I retested this and confirmed that on startup the Deskbar creates the settings file, and then when the Deskbar shuts down normally (only on a planned reboot), the settings are saved. When starting up again the settings are restored.

This process doesn't work well for components that might want to use the Deskbar settings but are not running at the time that the settings are changed. For example in 5026 I need to use the recent folders count setting, but if it's been changed since startup, it's not available in the settings file. There's probably some interprocess communication that I could do to retrieve the setting, but getting from the file seems much more straightforward.

I think the Deskbar should update the saved settings any time the user closes the Deskbar Preferences window. Thoughts?

I consider it a bug or undesired behavior in Deskbar that the settings file is not recreated if deleted upon Deskbar shutdown, but based on discussion a few weeks back this ticket is no longer valid. I resolved #5026 simply using a constant recent folder count specific to the Backgrounds preferences app.

Well, it is still valid, it is unexpected that if you delete the file, DeskBar does not manage to recreate it. This also probably means it keeps the file open all the time, instead of opening it on-demand when the settings change.

So it is less urgent than initially thought, but still unexpected and worth investigating.

Deskbar does not keep the file open the whole time, it reads the file in at startup into a data structure, modifies the data structure while running and then when the app quits (typically on reboot) it opens the settings file and writes the changes back to disk. I don't think it is doing any checks to see if the file got deleted in the meantime.