[Fixed] GZDoom eats and overrides config files

[JPL]

Just in case it's a useful data point and without speculating as to causes, I've been running GZDoom from Linux for over 10 years and I've never seen this issue.

[drfrag]

A question for people experiencing this issue, do you have any third party antivirus software installed and which one?

[SanyaWaffles]

I have Malwarebytes installed, however I don't have the realtime protection enabled. I find that stuff intrusive.

[drfrag]

I also have that antimalware installed, must be something else. Seems this is a windows only problem after all so a simple _stat check would do then.

[drfrag]

First i did the _stat version but then i upgraded it to C++ 17, PR here: https://github.com/coelckers/gzdoom/pull/1235

[Graf Zahl]

GZDoom already has a stat based FileExists function. Please use that. std::filesystem is not available on macOS 10.14 and lower so thanks to Apple being dicks we can't use it for the time being.

[Caligari87]

Sorry if this disrupts the path to the bug, I do want to briefly chime in and say this has happened to me at least once on Linux earlier this year. Weirdly, it resulted in a partial overwrite of my settings (some were preserved, some set to defaults). I have no idea why it happened and haven't been able to reproduce it.

[drfrag]

Okay, done another PR. https://github.com/coelckers/gzdoom/pull/1236

[drfrag]

Seems it's fixed in the PR but now i've found another issue on windows and it's potentially very serious. It's about the _stat function, it's broken and it's used by FileExists. If you remove the permissions (or it's blocked by something else) _stat returns -1 like if the file didn't exist. I'm using VS 2017 but i think it also happens in 2019 (_mental_ has reported it). I've confirmed that the internal version works properly with the PR, it's still in GZDoom guarded by #ifdef USING_V110_SDK71 and it's _wstat64i32 but now GZDoom uses _wstat64 instead. I don't know what would be a better solution here, either using the internal version or fileSystem::exists on windows.

[drfrag]

Having a look at the source at least you can't lose savegames so may be it's not that bad. There are two completely different FileExists functions and the _stat problem is in DirEntryExists and that one is used by BaseFileSearch , D_AddFile and AddFile (besides the uses of FileExists itself). So what should i do now? Probably it's better to upgrade to filesystem::exists in FileExists for now on windows only and later do the transition for other OSes (stat works there).

[drfrag]

I've done it but now i'm not so sure the "upgrade" to <filesystem> was such a good idea. For filesystem::last_write_time you can't convert from file_time_type to time_t until C++ 20, on the other side the time parameter is unused in GetFileInfo so i could just change the specification.

[drfrag]

Done another PR, the alternative would be to use the internal _stat function and change it to use 64 bit file sizes. Or report the bug to Monkeysoft and wait for VS 2021.
https://github.com/coelckers/gzdoom/pull/1237
Edit: closed it and opened https://github.com/coelckers/gzdoom/pull/1238

[Apeirogon]

Maybe, just maybe, it have a some sense to add "void CrashIfIniFileCannotBeRead(const ErrorReport& txt) const {}" function to next release of Gzdoom to try replicate this bug on large numbers of Gzdoom instances!?

[Apeirogon]

Just letting you know that happened again right now. And I didnt launch Gzdoom for quite some time. It was first time I launched it in two weeks I think.

[_mental_]

I don't know how many times I need to emphasize the right way of investigating this issue.

None of the provided reports didn't answer one simple question: was the config screwed during exiting from the first run or did it happen at beginning of the second one?

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.

What you need to do is to keep GZDoom running (or kill it from Task Manager to avoid writing the config file), copy .ini to other location, and make sure that last modification time is preserved.
Now you can figure out was the config already screwed or not. This way, we will have an answer to the question from my first quote.
And once again, if this happened to you, it's completely useless to just post about the fact. Doing this won't make it fixed any faster.