PDA

View Full Version : FGU Bootup test file writing issue ...



nasman
April 30th, 2026, 16:12
Hello, for quite a few weeks now, I have been getting a new error on boot for a PC I have had no issues on for many months. Right on boot up it comes up with:
"Unable to write test file to data directory (E:/my_data/my_fun/ttrpgs/fgu_data/)"

And then immediately registers another error, that itself has a very obvious error in it:
"Error: Win32 IO returned 1392. Path: E:\my_data\my_funtrpgs\fgu_dataest.tmp"

It is super obvious at least in the second message that someone didn't parse the string properly since they are using the escape character for a tab "\t" erroneously. I do not know if that is ALSO happening on the test file read, but suspect it is the case.

As I said this has never been an issue before. I have ALWAYS run my data directory from an external SSD as I move between multiple PCs often. I also have run this as admin with the same issue. There are no permission settings for this drive.

And to add one more piece to the puzzle. FGU works perfectly fine. I can still add assets, modify maps and have all the XML files update correctly. There is no actual read/write issue. So I think this is an error only on that "test file" boot up sequence.

Screen shot attached.

Nylanfs
April 30th, 2026, 18:42
I wonder if it's a mounting order issue. Or MS changed something so the SSD isn't actually fully mounted until the first time something queries it? If you open that SSD (or the listed data directory) and THEN start FG does it do the same thing?

nasman
May 2nd, 2026, 15:16
Yep, I had done that day one. On multiple computers. I am 99.9999% sure it is just the "\t" parsing issue. I could change my path name and never see this again, but that won't fix the core program. It's a string handling issue.

Moon Wizard
May 2nd, 2026, 17:21
I looked through the entire FG code base for the client and updater; and none of our code writes an "fgu_test" file and the only "tmp" file written is "test.tmp".
That error message is not generated by either FG code nor Unity code; but by the Windows operating system code indicating the error ("File or directory is corrupt or unreadable.")

Are you running any other "add-ons" to FG that may be trying to interact with FG? Like sound bridges, updater modifying, etc.?

Regards,
JPG

nasman
May 4th, 2026, 12:47
Yes I do have add-ons. I don't really "Use" them anymore as I only use FGU as a map display now. I will try uninstalling them (not sure how) or at least disabling them. It's odd because this is right on launch, so I haven't even selected a campaign or ruleset or anything. I've attached logs in case they have more details about all these errors. Looking in them, it does seem like something got corrupted at one point. But this is on multiple PCs with their own FGU installs. The only "common" thing is the FGU data directory is on this external SSD I've used forever.

Trenloe
May 4th, 2026, 13:10
Make sure that the file permissions to E:/my_data/my_fun/ttrpgs/fgu_data/ and all subfolders and files are set to full access (remove Read-only).

nasman
May 4th, 2026, 13:15
Alright, sorry for the delay it took a while for me to try turning off all extensions, etc. None of that mattered.
You were correct in that it was indeed a windows issue ... not FGU. I ended up forcing a disc check and after it came back with a clean bill of health, FGU was able to launch without that error.

So this issue can be closed. It was definitely some rogue process in windows tripping over itself to write out some tmp file that had nothing to do with FGU.

Thanks for your patience as always. As I said from the get go, FGU was always working fine, so I knew this was something very specific to my setup. Not sure when the issue popped up as I had been running this campaign for the last 18 months or so with no issue, and across multiple computers with different OSes. So it just came down to the shared SSD.

All is well. Thanks again helping me debug!

Nylanfs
May 4th, 2026, 17:03
Maybe be related to not dismounting the SSD before disconnecting it? Then Windows thinks there's a disc issue when it's reconnected?