Unprivileged users can't save settings

[teknowledgist]

At least sometimes, when Notepad3 is run by unprivileged users, the %APPDATA%\Rizonesoft tree is never created which means (at a minimum) that they can't save their settings.

When they attempt to save settings, there is an error message.

If they go to Settings -> Advanced Configuration -> Open Settings File (Ctrl+F7), they get the system-wide settings (C:\Program Files\Notepad3\Notepad3.ini) which shows the same global settings as on machines in which the users' settings are saved. Namely:

[Notepad3]
Notepad3.ini=%APPDATA%\Rizonesoft\Notepad3\Notepad3.ini

However, that file path does not exist.

If I manually create the entire file path in the user profile with an empty Notepad3.ini file, then they can save their settings. Creating the folders alone isn't enough.

If the global settings file points to a user settings file and it doesn't exist, shouldn't it be created?

Thanks for a great application otherwise!

[hpwamr]

HI @teknowledgist , here a detailled answer of INNO Setup Support (original in: Inno Setup Forums)

---

Hi,
When the installer is running elevated (with admin privileges), it cannot reliably access or write to the invoking user’s profile directories (such as %AppData%). This is expected Windows behavior and not an Inno Setup limitation. In an elevated context, %AppData% may resolve to a different profile/context than the user who started the installer, so “per-user” files/directories may be created somewhere else (and therefore appear to be missing for the user).

Also note that Microsoft is introducing an “Administrator Protection” feature. With this change, elevated processes run in a more isolated context, which further prevents elevated installers from writing per-user data in a way that will be visible to the launching user. In practice it can look as if those %AppData% writes “disappear”.

If the Notepad3 installer expects to create/copy files into the invoking user’s %AppData% during an elevated install, you should contact the Notepad3 installer authors about adjusting their installation logic.

Best regards,
Martijn

---

PS: We are trying to modify the installer's logic to resolve this issue... 🤔

[teknowledgist]

I understand and agree with the "limitation" of the installer, but I don't think this is an installer problem.

I'm saying that when a user starts Notepad3 and the global settings reference settings in %appdata% (i.e. in each individual user's profile) but the user's settings file doesn't exist, Notepad3 should create it. That is well within the capability because the user has permission to their own files.

If the %APPDATA%\Rizonesoft\Notepad3\Notepad3.ini file doesn't exist, users can't personalize their own settings.

An aside but related: When the the %APPDATA%\Rizonesoft\Notepad3\Notepad3.ini file exists (even empty), a CTRL-F7 opens it, but when it doesn't exist, the global settings open instead (which unprivileged users can't even change). Why is there different, incongruous behavior from a single action?

[lss4]

On the surface, I think Notepad3 first starts from system-wide Notepad3.ini, and upon reading a "Notepad3.ini" entry in the ini, replaces the current settings file path with the one specified there only if it exists, and read its contents afterwards. If the specified file doesn't exist, the active settings file path will not be changed and nothing else will be done.

I'm not sure this is exactly how it works. I'm in the process of reading Config.cpp and PathLib.c trying to understand the actual behaviors...

[lss4]

I think I've figured out the rough detail after further reading the related code a bit.

Notepad3 indeed starts from the system-wide settings file which would be Notepad3.ini in where the program is, putting this path into the Paths.IniFile global variable as initial value.

If the system-wide settings file exists, it will try to do _HandleIniFileRedirect(), which takes in the value of Notepad3.ini in [Notepad3] and checks whether the target file exists via _CheckAndSetIniFile(). If the target file doesn't exist, the function additionally checks a few other places before reaching the conclusion.

In our case, user settings file doesn't exist in the target path nor any of the alternative places, so _CheckAndSetIniFile() would return false and Paths.IniFile is not touched during the period. As such, Paths.IniFile still has the path for the system-wide settings file, so user settings file is not going to be created at this point.

I think this part certainly needs some refactoring.