MO2 Deleting Temp Folders Prematurely(?) Causing Path Not Found Errors

[ThisNekoGuy]

The problem:

After attempting to install some OMODs, I found that MO2 keeps requiring a specific folder: C:/users/USERNAME/AppData/Local/Temp But, after installing the OMODs, it's started to throw messages like:

failed to create temporary file for 'F:/profiles/Modded/modlist.txt', error 5 ('Path not found.'), temp path is 'C:/users/USERNAME/AppData/Local/Temp', -0.000GB available
failed to write mod list: Failed to save 'F:/profiles/Modded/modlist.txt', could not create a temporary file: Path not found. (error 5)

Because, it seems to keep deleting that Temp folder after attempting to install, thereby causing these errors... But what I don't understand is both why it's doing so and why it doesn't just recreate the Temp folder if it's upset that it doesn't exist (because MO deleted it) :/

To Reproduce:

(In my case)

1. Setup a portable MO2 v2.5.2 instance for Oblivion (I use the GOG version, but should be irrelevant I think)
2. Download the OMODs for Qarls Texture Pack III
3. Attempt to install them (I was able to trigger the problem with the first 2 (author intended) OMODs
4. MO2 becomes unable to update modlist information (Which you can verify if you moves mods around, close MO2, then re-open)

Environment:

• Mod Organizer Version that exhibits the issue: 2.5.2
• Last Mod Organizer Version that did not exhibit the issue (if applicable): Unknown (Haven't used MO2 in a long time)
• Desktop OS/version used to run Mod Organizer: Gentoo Linux (via Wine 9.21)

Details:

What I also found weird about this is that I installed other OMODs prior to the ones mentioned and had no issue until I specifically started installing the ones mentioned. If I recreate the Temp folder, the issue gets fixed, but not for long because attempting to install another OMOD from that mod page causes it to be deleted again. :/

Links to Mod Organizer logs:

USVFS:

• USVFS Log

MO Interface:

• mo_interface.log

[AnyOldName3]

It says C:/users/USERNAME/AppData/Local/Temp because our logger scrubs out the user's username from the log, so it's really your regular temp directory rather than a made up one that has USERNAME in it. If you're aware of this, and your regular temp directory doesn't exist, that's probably going to cause problems for other applications.

MO2 doesn't directly create the temporary file, it gets Qt to, and Qt doesn't create the temp directory because it's supposed to always exist. I'd expect that if you press the Windows key and R to bring up the Run dialog in Windows, and then type %TEMP& and press enter, it'll turn out that the temp directory does exist. If it doesn't, that indicates that either you've deleted it yourself at some point, or something's wrong with your machine.

Sometimes file error messages in Windows can be misleading, though. It's possible that the directory does exist, but your drive is full, and that would explain the -0.000GB available part of the error. Installing OMODs requires them to be temporarily extracted to the temp directory, so possibly that filled your drive up.

[ThisNekoGuy]

I opened up the file path and I assure you the folder is indeed gone :/ I powered through this OMOD circumstance and moved on with continuing my loadorder setup, and it's not doing it anymore (consistent with what I mentioned but only that, it seems); I was just forced to keep recreating the folder until I was done with what I doing (although, it was annoying).

so possibly that filled your drive up.

That said, my drive is nowhere near full yet, either, I still have close to 1TB of storage left.

[AnyOldName3]

It shouldn't even be possible for MO2 to delete the temp directory, so that's bad if it's managing to. This was happening each time you installed an OMOD? Maybe the step that clears the subdirectory that temporarily contains the extracted OMOD is accidentally affecting its parent.

[ThisNekoGuy]

This was happening each time you installed an OMOD?

Yeah, it was happening every time

Maybe the step that clears the subdirectory that temporarily contains the extracted OMOD is accidentally affecting its parent.

I considered this possibility too, but I wasn't completely sure of the likelihood given I'm not familiar with MO2 / Qt code