After upgrading from version 1.6x to 2.0x in Debian, Changing settings and Saving would not work for me on 1 (server) machine.
The solution was to close wfview, rename the wfview.conf in /home/.config to something else, then start wfview again, configure it, close it again, then copy/paste from the old .conf into the newly generated one things like login names and passwords for the server.
Leaving the previous .conf file to be appended seemed to confuse my install, Things like Radio Settings and new User Names and Passwords would not save.
This sounds more like a permissions issue on your machine, as we have not had any other reports of this and the core team all regularly use wfview on various linux distributions.
I would check the log as that should tell you what is happening.
I thought that too, but no amount of CHMOD CHOWN or tweaking of user groups would fix it. In the end, allowing the install to make it’s own fresh .conf, and pasting in the user/password lines worked just fine.
The previous .conf was from 1.6x, and comparing it to the appended .conf, and a fresh one, there are some differences in the content for sure, but the file properties were all the same. Bizzare.
Oh, my bad, /home/[username]/.config/wfview is where the .conf lives, of coarse!
Ah, it’s no big deal, everything worked, Just the settings were all stuck as they were on 1.6x, which was annoying. Making a change - like adding a user - then SAVE and restarting showed the save had not worked. There was no indication it did or did not work, it just reverted back to the state it was before the save is all.
Even now, with the freshly created .conf, with my users added by editing, the permissions and ownerships are all the same between the old one and the new one.
Could be a physical issue with the SSD? It’s new, but who can tell these days…
No drama, it’s working now. Just wanted to post as searching for the issue brought up nothing specific, and it’s bound to happen again, if not with someone else, with me
