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

Various installer bugfixes #2206

Open
7 tasks
t-b opened this issue Jul 29, 2024 · 2 comments
Open
7 tasks

Various installer bugfixes #2206

t-b opened this issue Jul 29, 2024 · 2 comments
Labels
bug Something isn't working Installer

Comments

@t-b
Copy link
Collaborator

t-b commented Jul 29, 2024

  • Remove suggestion for 32-bit MIES release, this is way too old
  • We had a a report that the installer is hidden after calling the uninstaller. This does not reproduce here
  • Remember "All user/Current user" selection from previous installation. Use registry if we already use it, otherwise a ini/json file.
  • When installing as normal user which does not have admin rights, then elevating to an admin user and then selecting "Current user" this installs for the admin user and not the normal uesr. Might be a NSIS issue.
  • The uninstaller is not signed, according to https://stackoverflow.com/a/72504367 this can with NSIS 3.08 or later be done using !uninstfinalize
  • Remove the "Permanently remove MIES" question and just do it.
  • Remove all and user installations on reinstalling if admin
@t-b t-b added bug Something isn't working Installer labels Jul 29, 2024
@t-b
Copy link
Collaborator Author

t-b commented Oct 14, 2024

@timjarsky

The last issue

When installing as normal user which does not have admin rights, then elevating to an admin user and then selecting "Current user" this installs for the admin user and not the normal uesr. Might be a NSIS issue.

is the one reported on slack, https://aiephys.slack.com/canvas/C06P3MYEV6H.

When looking at the installer code I can see how this goes wrong. For a normal end-user installer we request admin execution level.

And after that there is no way to get back to the original user for an "user" installation.

This is kind of on purpose from Windows because writing per-user data from an UAC elevated installer running as adin is considered bad practice, see https://stackoverflow.com/a/55537022.

Now if we want to fix it there are several ways:

  • (The officially advised way) Don't elevate the installer by default to admin. When run as non-administrator this would only allow a user installation. Vice-versa an admin run (rught click run as) installation would only allow an all-user installation. This basically makes the point of the letting the user decide moot.
  • Alternatively we could gather a list of users via https://nsis.sourceforge.io/User_Management_using_API_calls#Enumerate_all_users and then let in the all-user installation case decide under which user to install the files.

@t-b
Copy link
Collaborator Author

t-b commented Oct 14, 2024

We go for option 1 (officially advised way).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Installer
Projects
None yet
Development

No branches or pull requests

1 participant