Updater log errors

[Weissrolf]

Hello. I noticed the following error messages in my FGUpdaterEngine.log.


FantasyGroundsUpdater: A:\Onedrive\RPG\Fantasy Grounds Unity\FGUpdaterEngine/FGUpdaterEngine.exe not found
The last / instead of \ looks suspicious, but the main issue seems to be that Updater looks for the file in the Data directory instead of the Program folder?!


FantasyGrounds: A:\Onedrive\RPG\Fantasy Grounds Unity\UnityCrashHandler64.exe not found
No / here, but same issue of looking in the Data directory?!


e: OnApplicationQuit - Could not find shell C:\Program Files\SmiteWorks\Fantasy Grounds\FantasyGroundsUpdater.exe To self-update!
This time the directory is correct, so I guess that this error only happens when no self-update is present and thus can be ignored?

[Moon Wizard]

Can you please provide your full updater logs from the Troubleshooting section of the Settings in the Updater?
This will provide us with all of the settings for your FG install to see if we can recreate.

Regards,
JPG

[Ecks]

FWIW, I see the same 3 log errors in my updater log as well, after running an update when there were no updates to download (i.e. run an update and then run it again). I've seen these errors appearing in my updater log for a long time, but they never seemed to cause any issue.

[Weissrolf]

File send via support e-mail. This one is from the TEST channel, because I just switched to it for testing an extension. What I noticed is that now the files are listed as missing from the VAULT.

FantasyGroundsUpdater: A:\Onedrive\RPG\Fantasy Grounds Unity\channels\Test\vault\FantasyGroundsUpdater.da t not found in vault
FantasyGrounds: A:\Onedrive\RPG\Fantasy Grounds Unity\channels\Test\vault\FantasyGrounds.dat not found in vault

No / before the file-name this time. So overall it looks like the errors want to tell us that no updated files are present to be handled.

[damned]

Completely unrelated Weissrolf but do you have OneDrive syncing a network share?

[Weissrolf]

The network share is on a Synology NAS, which also does the syncing. So the local PC running FGU does no Onedrive syncing anymore (which never caused issues, though). Instead the FGU data folder is set to Offline files in case that the NAS is ever not reachable. Mostly only seems to spare me having to run the OD client on the PC and allows me to use filesystem snapshots (BTRFS) for FGU files, which happens every hour instead of just one a day (PC backup).

I am not sure yet if one (local OD) or the other (NAS OD) solution has any other benefits. In practice it doesn't seem to make much of a difference, because the bottlenecks with FGU are not in accessing the files locally or over network (vs. M.2 SSD), but having to access many small files and generally being *very* CPU/Lua bottlenecked.

For a time I also tried Dropbox, because it is faster at syncing many small files. But that is only true for its original Windows client, while all third-party clients (like Synology) are bottlenecked into only a single concurrent connection to the Dropbox server. Furthermore I noticed that updating WoW addons via clients like Curse or WowUp oftens fails for single addons while Dropbox does its syncing, so I trust it a bit less than Onedrive for FGU data (plus I own more OD space). It never was a practical problem during Wow gameplay or logging off, though, where much writing/syncing happens.

[Moon Wizard]

Accessing many small files is what FGU does; because it is reading all the various asset files, ruleset files and extension files installed from various products and community efforts. It only reads in what it needs; and may need to discard and reload assets based on memory usage. As mentioned before, a network drive is not recommended due to the latency added to every file access. I just bring up when we have these discussions, so that other users are aware of our recommendations.

For the logs you sent to support, they do not have the information in the logs as the logs are reset when the updater restarts. You can either send the FGUpdaterEngine.log file from the FG data folder immediately after launch; or use the Settings button to access the updater application without the auto-close flag so you can update and pull logs in the same updater session.

EDIT: Apologies, I didn't notice we were already pulling the "previous" log; so the data is there.

Thanks,
JPG

[Weissrolf]

I did some time measurements of load time with my main campaign of 8 modules + 22 extensions. 22 seconds for local files (M.2 SSD), 32 seconds for online NAS files (1 gbit Ethernet) and curiously 45 seconds for offline NAS files (Windows offline cache).

Just let me know if you need any more log data. This doesn't look like any serious bug anyway, albeit that / instead of a \ is worth looking at.

[Lo Zeno]

Just let me know if you need any more log data. This doesn't look like any serious bug anyway, albeit that / instead of a \ is worth looking at.
If that folder is a network folder mapped from your Synology NAS, I wouldn't worry about the / at all. Synology DSM is a linux based os, which uses forward-slashes for the path; when you map it to a network folder in Windows, normally Windows "translates" all the / to \ automatically, but there are rare instances in which it doesn't - yet, it's a non-issue, because while \ is the standard path separator in windows, / is still a valid path separator (it is, indeed, called "alternative directory separator" inside the Windows system).

[Weissrolf]

Depends on where it is used. / works in Windows explorer, but not in the command line, then again it works in Powershell.

[Lo Zeno]

Depends on where it is used. / works in Windows explorer, but not in the command line, then again it works in Powershell.

Speaking strictly about Windows 10, not the versions before, cmd.exe is the only place where a forward slash is not accepted in paths since it is used for switches and options in its applications. But at the OS level, in Win32 apis, .NET apis (and powershell since it's built on .NET), and the so-called "UWP apis" (Microsoft Store apps), everything already handles the forward-slash to convert it to backslash. Even when you create a zip file from Explorer, the relative paths inside are rendered with the posix-compliant character /, instead of \.
CMD is the one exception, not the rule, and only due to backwards compatibility with DOS applications.

[Weissrolf]

Great insight, thanks for that.