Re: GZDoom eats and overrides config files

Wed Nov 04, 2020 4:57 pm

I first encountered this at the end of August, made a post asking about command line parameters. I have been doing something similar to Apeirogon, I've been directing ZDL to an ini not in the same folder as GZDoom, and yes sometimes it still manages to corrupt that ini, but less reliably. Sorry I cant give a version number, I've updated since then, but I can say I ran with the problem for a couple weeks before my post asking, so my earliest encounter with the problem would be mid-August.

Re: GZDoom eats and overrides config files

Thu Nov 05, 2020 10:04 am

Apeirogon wrote: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.


If you start GZDoom with a command line flag to use alternate config file, it uses that path instead of the default.
So the same sequence - gets error on reading your gzdoom_portable.ini file, assumes file does not exist, loads standard settings and saves the "new" file in the location you specified.

Try gzdoom -config testnonexistent.ini - it will create the file right there (and possibly abort with no iwads found, depending on where you store them). :)

Re: GZDoom eats and overrides config files

Thu Nov 05, 2020 11:58 am

https://zdoom.org/wiki/Configuration_file
GZDoom supports portable configuration files: if the engine finds a gzdoom_portable.ini file, it will use that file instead of the user-specific one.

The only command line arguments that I use is "-nosoun -norun -vm_jit true", because Im too lazy to type nosound/norun/vm_jit false every time I run something to test it.

Re: GZDoom eats and overrides config files

Thu Nov 05, 2020 1:08 pm

Well probaly the longline thing in ReadConfig wasn't necessary after all. But FConfigFile::WriteConfigFile is called at exit and FileExisted is set to false in the previous FConfigFile::LoadConfigFile snippet.
Code:
bool FConfigFile::WriteConfigFile () const
{
   if (!OkayToWrite && FileExisted)
   { // Pretend it was written anyway so that the user doesn't get
     // any "config not written" notifications, but only if the file
     // already existed. Otherwise, let it write out a default one.
      return true;
   }

Seems somehow GZDoom can't open the file and assumes it doesn't exist. What about using fstat instead of Open in FConfigFile::LoadConfigFile? (i think FileReader::OpenFile uses Open and that would require extending FileReader with another function).

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 12:52 am

Happened again. I can safely confirm it was absolutely sporadic. No premature termination or anything, just using "exit" in console.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 3:30 am

How about adding a FileReader::CheckFile member function then?

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 4:00 am

How about figuring out what exactly went wrong instead of speculating about the cause?
None of the provided reports didn't answer one simple question: was the config screwed during existing from the first run or did it happen at beginning of the second one?
Without knowing the answer, all these fix suggestions are pure guessing game.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 4:12 am

As i understand it it's neither of the two, a random run when the file can't be opened becouse it's blocked by something else.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 4:23 am

Fix this "something else" then. If it's blocking file from reading, and then, it allows writing to the same file, we really need to know more details about this "something else".

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 4:51 am

Something else is some windows stuff. But are they getting their configuration or the engine defaults? LoadConfigFile could fail at startup and later on exit WriteConfigFile could overwrite it. I think the problem is that the code doesn't really check for file existence and just trying to open the file is not a good idea anyway. But making it portable is a bit tricky, boost::filesystem::exists?
If their configuration is loaded fine then no idea what's going on.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 5:00 am

"some Windows stuff" does not block files from reading. It's most likely some other kind of shit that opens files so that other processes are blocked from reading it.

As for how to handle it, what would you suggest? Abort with an error "unable to read config"?
All I can say is that I never had such an error ever.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 5:16 am

I have never tested the theory, but I have seen it suggested if you quit GZDoom while it is still loading (i.e. before the titlepic appears), that can increase the chances of it happening.

It's never happened to me either though.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 5:32 am

Graf Zahl wrote:Abort with an error "unable to read config"?

If this is indeed the problem it might be the best way to handle it.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 5:37 am

I don't think that's necessary, WriteConfigFile pretends the file was written anyway if it exists. Just writing a warning about the config not being read?
Edit: true it's probably better to abort else it would be confusing (after dealing with OkayToWrite of course).
Edit2: well users would not get their config and after changing the settings they would not be saved, you could warn about that too but could be annoying.

Re: GZDoom eats and overrides config files

Sun Nov 15, 2020 7:21 am

Would there be any value to GZDoom making a copy of the old ini when it starts? [username].ini.bak?

Personally, I'd find that quite useful anyway regardless of this issue.