KVIrc fails to save and restore settings sometimes

[Stanzilla]

Recent issue so probably maybe a regression: Sometimes when restarting the PC or logging out, KVIrc loses certain settings, like which theme was selected and on/off toggles for some settings. This never happened until ~1-2 week(s) ago.

I could make a list of which settings it loses (it's always the same) but not sure if relevant?

Examples on what is lost:

• Which Theme is used
• Prepend gender info to realname
• Prepend avatar info to realname
• On Channel Kick: Rejoin channel
• Automatically join channel on invite
• Request missing avatars
• Automatically accept incoming avatars
• Remember avatars for registered users
• Enable lag meter
• Require 'Control' to be held down to copy text
• Enable tray icon

Also when I closed and reopened it after changing all the settings again it kept those, yet after the next "crash" it lost exactly those again.

There is at least one other user having the same issue on #kvirc. Just creating an issue now so I don't forget and can maybe add more details as I figure them out later on.

KVIrc 4.3.2 'Aria'

Runtime Info:
System Name: Windows Release : 6.2.9200
System Version: Windows 8 Professional with Media Center (x64) (Build 9200)
Architecture: Intel64 Family 6 Model 58 Stepping 9

Build Info:
Build Date: 2015-11-10 14:39:58 UTC
Sources Date: 20151110
Revision Number: git-5695-g21bd02f
System Name: Windows-6.2
CPU Name: AMD64
Build Command: C:/Program Files (x86)/CMake/bin/cmake.exe
Build Flags: 
   MANDIR=share/man
   CMAKE_INSTALL_PREFIX=C:/projects/kvirc/build/release
   Threads=Win32
Compiler Name: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe
Compiler Flags: /DWIN32 /D_WINDOWS /W3 /GR /EHsc

[un1versal]

Here is what Ive noticed/observed (while testing other somewhat related issues)

No settings are being written to file in user config directory as you change/apply something, things seem to be held in memory and then somehow (if you're lucky) when you close KVIrc things maybe then saved.

You can test this yourself easily; (this is what happens here in Linux anyway I presume Windows behaves the same?)

1. Start KVIrc, open a config file (in a text editor) and check a value for some setting, remember that value close that file
2. Now goto KVIrc settings find that setting and change it and click apply
3. Now reopen that file again and find that setting value (it should be what you set but is still same as it was)
4. Keep file open and close KVirc, shortly after your editor should detect file was changed and notify you, accpet file changes/refresh it as editor probably will ask you.
5. Look up that setting (you will see its the value that you changed to in step 2.

My guess is that the settings being held in memory are lost somehow, no idea really how to fix.

[Stanzilla]

Sounds like options saving should be moved to an event triggered system then?

[wodim]

afaik kvirc does not save settings automatically when you change them, they are flushed from time to time and when you quit the application. So if you forcibly close kvirc, they are not saved, of course...

[Stanzilla]

Yeah would make sense then to flush them when the options window closes, imo

[un1versal]

imo it makes sense to save soon as apply is pressed and config files reloaded, if thats what you said means.

[Heufneutje]

Unless KVIrc itself writes things to the settings while it's running, I agree that it makes more sense to just save them when OK/Apply is pressed.

[un1versal]

In any other softwares OK never saves anything its more or less behaves like close, apply is when things should be saved, in any case as its done currently is unstable and prone to failure, even though I havent quite experience the degree of chaos the OP describes.

I would even make apply greyed out unless a change happens, when you chnage something button comes active to confirm visually that something has changed, once pressed it should grey out again.

(Ive no idea here anyway this is just academic discussion to me.

[DarthGandalf]

In any other softwares OK never saves anything

No. You're describing Cancel, not OK.

[un1versal]

OK here does nothing to save anything. Pressing OK closes the window.

also if I change some setting it definitely doesn't change anything for the related setting even on Kvirc reload. at least that what I observe here.

[un1versal]

@Stanzilla can you try to run /options.save command when you change settings and see if that helps any?

[wodim]

/options.save actually runs when you click Apply or OK.

https://github.com/kvirc/KVIrc/blob/master/src/modules/options/OptionsDialog.cpp#L621

[pragmaware]

Yes. g_pApp->saveConfiguration() runs when OK is clicked in the options dialog.
If you can reproduce the bug systematically then please make it "crash" (however you do it)
and then take a look at the configuration saved on disk (before restarting KVIrc).
Are the settings saved properly in the configuration?

[Stanzilla]

It happens when Windows closes KVIrc when it tries to shutdown. I can repro it 100% with that. If you have the setting to require confirmation on quit enabled, the shutdown will be blocked and you won't run into this though.

[un1versal]

The porblem is that settings arent written to disk until you close kvirc, else things are left in memory, something happens to that memory and poof, gone.

@staticfox noted that on IRC and this is a real issue hence added to blocker milestone.

[karai17]

This is still happening and it is becoming very frustrating. The other day when I restarted my pc, kvirc's theme and position and windows size were all reset to default. Setting the theme back to the theme I use, some of the theme's settings were missing. Today I just lost all of my auto-login information, so now I need to set all that up again.

How is this even happening? How does kvirc manage to seemingly randomly remove sections of, or entire files? Why is it even touching these files to begin with?

[IceN9ne]

@karai17 what OS are you using and are you using a recent nightly or an old release?

[karai17]

I am running Fedora 24 and using whatever is in the Fedora repos. It is
labeled as 4.9.1

---

Landon Manning
lmanning17@gmail.com

On 15 November 2016 at 01:46, IceN9ne notifications@github.com wrote:

@karai17 https://github.com/karai17 what OS are you using and are you
using a recent nightly or an old release?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1744 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAkB_LliZp_gmPKcPe59OrkkmQ_YBPguks5q-UdEgaJpZM4GiKPp
.

[Stanzilla]

it still happens on Windows, too btw.

[IceN9ne]

If the settings were saved, then a crash will not cause the settings to be "lost". Settings are saved when you click ok/apply. If settings are changed after you come back from a crash or forced close, then either the wrong settings are being loaded on next run, or something in KVIrc is overwriting the settings on load (as if it's first run?).

[IceN9ne]

@Stanzilla

Can you check the settings (maybe create a backup), force a crash (or whatever it is to cause this issue), and then before you open KVIrc again, manually check the config to see if it's what you expect? Pick a few of the ones you say are always changed. Also, what are they always changed to (I.E. are they always reset to KVIrc defaults)?

[wchristian]

@Stanzilla
Can you please do some change in your settings that would get lost; zip up your Settings\config dir; shut down windows and reboot; then zip up the Settings\config dir again before starting kvirc; then start kvirc and verify the change was lost; then upload them somewhere?

That way they can be compared usefully.

[Stanzilla]

I can't repro anymore. Either the issue is gone or KVIrc has to go into a "bad" state before it happens.

[wodim]

Reported on IRC as "still happening"

[PKEuS]

This is not fixed. It still happens in current builds on Windows. The only hack that helps is to make the config directory write-protected, which then generates an error message whenever closing KVIrc, but it can no longer destroy its own files.

Apparently, KVIrc shoots into its own foot when it is requested to close by the OS. Maybe it kills the thread that writes the files, or something like that. However, it is insane to save settings on closing anyway, regardless if they were changed or not. If this behaviour was changed to "save when changed", the issue should be gone in 99% of the cases.

[IceN9ne]

The only person to state what settings were lost was Stanzilla who confirmed that the only settings he lost were ones he changed outside of the Configure Settings/Theme dialogs and didn't properly close KVIrc after changing them. I looked at the code, and this situation is inline with how the code is written.

However, for losing settings due to a failed write, nobody has ever showed any corrupted .kvc files, stated which settings were lost due to such a failed write, or any other statement other than over-generic claims with wild assumptions.

[PKEuS]

didn't properly close KVIrc after changing them.

It does not depend on the close after the change. It happens also when nothing changed, and the OS asks KVIrc to close. Stanzilla described exactly this behaviour.

stated which settings were lost due to such a failed write

This varies. Sometimes its the theme, sometimes its the alternative nicknames, sometimes its the "don't show this window again" option. The last time I had the issue, KVIrc forgot its entire server database.

wild assumptions

Really? It is not a wild assumption that KVIrc constantly writes files which don't need to be written. Just look into the code (KviApplication::~KviApplication())...

[IceN9ne]

Give examples of what the config file looks like after such a situation occurs so that we can tell if it's a failed write or some other issue. Without confirmation, it's likely this issue will never be fixed. You're assuming the cause without any proof.

[wodim]

It's not a problem that KVIrc is writing files that don't need to be written. The problem is when those files get corrupted.

[IceN9ne]

I'd still love to see an example of such a mythical corrupted file.

[Stanzilla]

I'm on vacation atm but I can try again when I get back home. I always did the same to cause it, just shutdown Windows while KVirc is running and let it kill it this way.

[PKEuS]

It's not a problem that KVIrc is writing files that don't need to be written. The problem is when those files get corrupted.

It is a problem that KVIrc writes unhanged data, however it is not the "root cause" of the data loss. The data loss can also happen when the files are saved because they were changed. But writing them much more often than necessary increases the risk of loss (apart from other considerations like performance and SSD lifetime), so yes, I would consider this as a "problem" itself.

Anyway, I will temporarily remove the write-protection, and try If I can generate a broken file.

[Heufneutje]

I personally haven't run into this issue despite closing KVIrc through Windows shutdown quite often. But only saving the config files when actual changes occur is probably a good thing to do.

[IceN9ne]

"Saving the config file when actual changes occur" would require almost a complete rewrite of the settings system. The way it was originally written requires the files to be committed on close.

[karai17]

I would pose that idea that committing on close is faulty design and that a complete rewrite, if necessary, should be done. It is infuriating when I change a setting in any program, and then if the program doesn't close properly, that setting is lost. Commit it when I click "Apply" or "OK" or "Save" etc, that is the most sensible thing to do.

[PKEuS]

I'd still love to see an example of such a mythical corrupted file.

Here it is, main.kvc consisted of just one line this morning:
# KVIrc configuration file

KVIrc still knew which channels to enter, but it forgot to hide some windows and it forgot its themes and several other settings.

After closing KVIrc again, it was filled with default settings.

[wodim]

@karai17 We commit on apply/ok. https://github.com/kvirc/KVIrc/blob/master/src/modules/options/OptionsDialog.cpp#L636

[wchristian]

Bit of a shot in the blue: Maybe the saving procedure can quietly fail at any of those steps? (unchecked error returns and such)

[wchristian]

It also appears to me that a failed writable check can lead to a file such as @PKEuS described above:

KVIrc/src/kvilib/ext/KviConfigurationFile.cpp

Lines 343 to 351 in 96ca5fb

	KviFile f(m_szFileName);
	if(!f.open(QFile::WriteOnly | QFile::Truncate))
	return false;
	if(f.write("# KVIrc configuration file\n", 27) != 27)
	return false;
	if(!f.flush())
	return false;
	f.close();
	return true;

The close might also need checking maybe?

[PKEuS]

As this issue just happened again to me (this time, the entire server list was flushed), and I am now once more forced to reconfigure each and every server I connect to, I just want to let you know: I am tired of it. I will switch to a different client after using KVIrc for more than 10 years. I need an IRC client that is reliable and that does not need a write protection flag on its settings (causing an error message on closing - just as annoying as reconfiguring the entire client every two or three weeks). Closing the IRC client must not be a dangerous action. Even though if this means that I basically loose all my IRC log files (or at least a convenient way to read through them).
Apparently, the KVIrc team is not willing to fix the issue. Actually, some of you are not even willing to accept that there is a serious bug. Neither are you willing to acknowledge that it is a serious design flaw in KVIrc that it is touching and writing all settings files when closing KVIrc (I remember the discussion on that topic in your IRC channel half a year ago). And finally, you were not interested in getting support to fix this issue, as my attempts to find out what is going on were just called "wild assumptions" and "over-generic claims". wchristians suggestions seem to be ignored, too. I just regret that I did not immediately switched to a more stable IRC client when this bug happened to me for the first time a few years ago. That such kind of an issue can occur even one time should have been a warning signal to me.

[Soulflare3]

In the same boat here. I rebooted into safe mode to fix a GPU driver (DDU) and when I booted normally again KVIRC had "forgotten" its configuration once again. Very tired of reconfiguring the client from scratch. In this case my main.kvc and serverdb.kvc files are NOT empty, yet all of the other .kvc files are and KVIRC loads to a blank white window.

At this point I'm done, I won't configure KVIRC again.

[pragmaware]

Check out #2417 . It may have fixed the issue. Reopen if it still persists.