We get the APPDATA path via the Windows API in places(_*).go. We found this to be more robust than using the environment variable itself.

But recently we have a customer who fails to launch the bundled application. Upon inspecting the logs, we noticed that APPDATA is resolved to a netowrk-path (starting with //... instead of a mapped drive) and suspect, this could be an issue.

We need to locally reproduce this issue somehow or fake it somehow, pretending that the APPDATA is a network drive. It might be enough to inject it for testing into trivrost at the point where it launches the bundle. If it fails on a network mapped drive, we got the culprit and need to fix/support it somehow.

EDIT: The current code also causes problems in goal determination if a Windows user has configured lower-case driver letters for APPDATA. (Fixed in 1.5.0-rc1)