GZDoom eats and overrides config files

[Major Cooke]

In order to investigate this, I'm going to need to find where and when GZDoom begins and writes out a new INI file, if it fails to find and/or read an INI file.

This bug is completely sporadic, so I suspect something isn't initializing properly when it happens. Ever since the new fullscreen variable was introduced, somewhere around that time, I've encountered moments of starting up where it just completely disregards the INI previously made and wipes it out.

[SanyaWaffles]

So that explains why that happened to me the other night. I thought I was going insane.

[Major Cooke]

Yeah I did too. This is annoying. It happens so rarely though.

[_mental_]

In order to investigate this, I'm going to need to find where and when GZDoom begins and writes out a new INI file, if it fails to find and/or read an INI file.

You can start from here.

[Major Cooke]

Unfortunately I haven't had much luck in tracking this issue. This is harder than I thought... Or maybe I'm overthinking it.

[Major Cooke]

This bug is still an issue as of 4.5. Can I please reopen this? It happened to me just today.

[Rachael]

I think what should be done going forward is making automatic backup copies of the configuration files, even if they end up being shoved into a folder.

[drfrag]

I don't think LZDoom is affected, this has never happened to me. I wonder since when this is a thing but must be something recent.
In LZDoom the code in FGameConfigFile::FGameConfigFile () is exactly the same so the problem must be somewhere else.

[Graf Zahl]

Same here. I never ever lost a config file so it should be examined what other contributing factors may be there.
This sounds like GZDoom for some reason cannot open the INI - so what may block it?

[Accensus]

Just to make sure, you're not closing GZDoom while it's loading, right? Because I'm 99% sure that's what's causing GZD to eat my config files. You just have to time it reaaaaally carefully to trigger that. 10/10 times it's happened to me while I was opening and closing GZDoom all the time while modding. Haven't had a config get eaten ever since I started waiting for it to launch properly before closing it if I opened it by accident.

[Major Cooke]

I've been very consistent on just opening the console and typing "exit" in.

[drfrag]

I never use that but certainly the code is different.

Code: Select all

CCMD (exit)
{
	if (!insave) throw CExitEvent(0);
}

Code: Select all

CCMD (exit)
{
	throw CExitEvent(0);
}

[InsanityBringer]

The last time I had it happen, I used the new relaunch button on script errors. I've also had it happen in a few cases when closing the startup window when the game is launching because I started it up twice by accident or something.

[drfrag]

If the file can't be read it assumes it doesn't exist:

Code: Select all

void FConfigFile::LoadConfigFile ()
{
	FileReader file;
	bool succ;

	FileExisted = false;
	if (!file.OpenFile (PathName))
	{
		return;
	}

	succ = ReadConfig (&file);
	FileExisted = succ;
}

And FConfigFile::ReadConfig is different in both versions.

[Apeirogon]

It then should create new gzdoom_<user name>.ini file.
Problem is, it eats/override existing ini file. I have my ini file renamed to gzdoom_portable.ini and Gzdoom still sometimes (rarely) corrupt it. I mean, if it was just "du du dudu....cant find/read ini file, well create new one then....gzdoom.get_name() + _ + windows.get_user_name()", as it should by default, but no, Gzdoom aware that it should use _portable name as a name for the "new" ini file.