GZDoom eats and overrides config files

[Apeirogon]

Maybe this bug was fixed/resolved and somebody forgot to mark topic close, maybe after some commit something clicked in Gzdoom and it stop from happening, etc.
In any case, ok, now I have step by step guide how to report it properly.

[drfrag]

But what version are you using? The bug is fixed in LZDoom and it was pretty simple, the code made the old assumption that the file doesn't exist if you cannot open it instead of checking for file existence, then the check itself was broken too on windows. That said this bug is very rare and never happened on any of my machines, you could investigate what processes are running in the background on your system. That's completely irrelevant to fix the bug tough, the code was obviously wrong.
https://github.com/coelckers/gzdoom/pull/1236/files

[Graf Zahl]

Are you *sure* that this was the reason or is it just conjecture? Have you ever seen conclusive proof that this actually failed?

[drfrag]

As i said i never got this bug but can be easily reproduced removing permissions from the file before running the engine and then restoring them before exiting, the ini will be overriden. Then there was the _stat problem on windows so i made another PR to use the internal function.

[Apeirogon]

But what version are you using?

Gzdoom 4.5.something with some custom changes, unrelated to file operations.

[Major Cooke]

Okay... I think it's related to the Restart button added. I think there's a chance that when it re-opens the program, the previous instance of GZDoom may not yet be closed. This is whenever the parser encounters an error and execution cannot continue, specifically. That was one way I was able to replicate it... Barely. But if I just do "quit" and launch it again manually, it doesn't happen since there are no other instances open.

Maybe that might be it. I'm not entirely sure.

[Graf Zahl]

I think you are right. The restart button just generates a WM_QUIT message, which later causes an ExitEvent to be thrown, which initiates a controlled shutdown. And one action in a controlled shutfown is - you guessed it - saving the config - while at the same time the new process will try to read the config and is being blocked by the old one which still has the file locked.

I don't think that posting WM_QUIT in this situation is even remotely safe.

So, @drfrag: This is precisely why I never bothered with your workaround - it would have hidden the real problem, making it even harder to find and fix. It is always a bad idea to fix the symptoms without finding the cause.

[drfrag]

Interesting but that doesn't change the fact that the original source was wrong and FileExists is broken on windows. When pressing restart with my changes you should still get the config error and be able to investigate the problem. And according to previous reports i'm not sure it cannot happen in other situations.
@Major Cooke could you put a runnable sample?

[Graf Zahl]

Runnable sample? Press "Restart".

[Major Cooke]

It doesn't happen all the time. Just sometimes. So it's still as enigmatic as any other.

[Graf Zahl]

No, that's to be expected. Sometimes the two processes do not overlap their access, sometimes they do. A classic case of unsynchronized access to a non-shareable resource.

[drfrag]

Okay i can't reproduce it with a bad zscript.txt, even restarting many times.

[Major Cooke]

It's pretty rare when it happens. If anything I'd suggest loading up intensive mods that take a lot of memory for example such as AEons of Death. Maybe it having to unload more may trigger it to occur more often? Just a guess, but perhaps that may cause more overlap.

[_mental_]

Interesting but that doesn't change the fact that the original source was wrong and FileExists is broken on windows. When pressing restart with my changes you should still get the config error and be able to investigate the problem.

Your proposal won't change anything. The config file does exist, but it cannot be opened for reading because it's already opened for writing.

[drfrag]

Precisely, i added a check for file existence but you assume that the file doesn't exist becouse it can't be read. It's a bad habit usually seen in old code.
Are you sure that it cannot happen without pressing the restart button? That said that should be fixed too if it actually happens.