Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Install location might not be writable at runtime #924

Open
DeinAlptraum opened this issue Dec 2, 2024 · 1 comment
Open

Windows: Install location might not be writable at runtime #924

DeinAlptraum opened this issue Dec 2, 2024 · 1 comment

Comments

@DeinAlptraum
Copy link
Contributor

Actual behaviour

The config.ini is located in the installation directory, and it is overwritten when options are changed, including every time one passes through the player-selection screen. Depending on the install location and the executing user's permissions, this might fail, thus crashing the game with an error "Unable to create file".

Expected behaviour

Under Windows, programs are expected to save their relevant configurations etc. to ProgramData or similar user folders. This should ensure that config.ini is writable, allowing the player to change options and play the rest of the game without crashing.

Steps to reproduce

Disclaimer: I haven't encountered this issue myself, but seen it brought up by Windows users several times.

I assume it could be recreated by e.g. letting an admin user install USDX, and then letting a regular user start the game or similar.

Details

Provide some additional information:

  • USDX version: 2024.10
  • Operating System + version: Windows 11
@basisbit
Copy link
Member

basisbit commented Dec 2, 2024

UAC since Windows Vista will relay writes to a non-writeable Programs folder into the users AppData folder (which behaves as a virtual overlay). This should only break on systems where UAC is turned off (usually by a sysadmin on purpose) or when users manually copy the USDX folder to the Programs folder.

Admin user installing USDX and then a non-admin opening it works fine on Windows. The way how USDX since 1.3 does it is exactly how applications should behave since Windows Vista.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants