Re: GZDoom eats and overrides config files

Wed Mar 03, 2021 2:56 pm

Again, try a more resource intensive mod. It has to unload more stuff when it restarts. That might make it easier to trigger. Particularly a mod with a lot of content.

Re: GZDoom eats and overrides config files

Wed Mar 03, 2021 5:54 pm

Two separate instances of Gzdoom launched with broken code produce, with restart of one of them, same result. But that was to be expected.
Day, month, year
"Today" version
new — копия.png

2051 year version
new — копия — копия.png
You do not have the required permissions to view the files attached to this post.

Re: GZDoom eats and overrides config files

Thu Mar 04, 2021 6:41 am

No, for me it doesn't happen with two instances. Same restarting only one with BDv21 and a bad zscript.txt twenty times in a row.
Edit: just happened now only with the bad zscript.txt.

Re: GZDoom eats and overrides config files

Thu Mar 04, 2021 8:02 am

I know in Windows at least you can easily look up the shares of a file - I am not sure what functions are involved - but if there's any other process that has it open for writing (I think you can check for that too) it can wait for up to 5 seconds for the operation to complete and if it doesn't - then it could error out and tell you it can't read the config file.

But that might not solve the race condition completely.

Re: GZDoom eats and overrides config files

Fri Mar 05, 2021 2:01 pm

But where? I've done some investigation and i'm lost here.
I can reproduce it consistently pressing restart but i don't know where the problem is. Some food for thought: after pressing restart several times i can see the config has been reset at the iwad selection startup window. You can see that easily selecting another backend different from the default one and saving the config earlier. Then i've noticed that when you press exit in the picker the config is not saved so when i see that the settings have been reset and exit the config file is not overriden. If i restart again of course i lose my config file.
With my code (but it's the same in GZDoom) i can see putting a Printf that the file is opened succesfully and the succ variable is true every time even when the config is reset. If i remove the read permission from the file before restarting i get the "Could not open config file error message". And it's not something related to saving since i exit without saving and i never get the dialog with the "configuration not saved" error.
Code:
void FConfigFile::LoadConfigFile ()
{
   FileReader file;
   bool succ;

   FileExisted = FileExists(PathName.GetChars());

   if (!file.OpenFile (PathName))
   {
      if (!FileExisted)
         return;
      else
         I_Error ("Could not open config file.\n");
   }

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

Re: GZDoom eats and overrides config files

Tue Mar 09, 2021 6:11 am

It was a corrupt config file and the configuration was reset, i've added a check for that and then you can restart again.
https://github.com/drfrag666/gzdoom/com ... aa748a848d
Edit: i've noticed that my post was a bit confusing. What's happening here is that the file is still being written while being read so a lock would be required like Cacodemon345 said but that's not that simple so i agree his solution is okay. Nonetheless i wanted to add several checks to see if the file is a valid config (actually if you load any random text file you'll silently get a factory default configuration which is fine in most cases), that also helps becouse OkayToWrite is false at that point. So i wanted to know what was going on and now i do, if i remember right some people have reported partially reset configurations.