WakeOnLAN
WakeOnLAN copied to clipboard
basildane
dbPath setting resets to default after manually editing user.config
I have quite a baffling issue after updating from 2.11.15 to 2.12.4. I'm used to adding WOL to new users by just copying the directory from another user's AppData\Local and changing the username in the 'dbPath' key in user.config. This worked fine until I updated.
What I'm observing is that when WOL is started, it changes the path back to the system-wide default machines file in ProgramData. No matter how many times I change it and restart, it always changes back. But if I go and set the path using the Options UI, that way works! And if I then compare my manualy edited user.config with the newly updated one, they're binary identical...
I don't understand why this is happening. I was not able to identify any additional config save locations, but I may be missing something. For now I will fix all users using the UI, except one which I will leave as-is in case I need to reproduce this later.
The way that Microsoft uses the GAC to store user settings is kind of confusing. I'm nearly certain that you are editing the wrong user.config file. Each time you update the application, another folder is created in the GAC and possibly a new user.config file. What you are trying to do should work, just make sure you have the right user.config file.
I tried deleting all the previous contents first. There's only 1 config left. It also happens to newly created accounts which haven't run WOL before.
I am revisiting this because I had to create 10 new user accounts and every single one of them was hit by this. Today I experimented somewhat, and found that it's not just new accounts - I can trigger this bug at will in my own, already established profile.
I was unable to trace this via Process Monitor for reasons explained below, however I did discover that if I change the filename of the machines.xml file in user.config in addition to changing the directory, the directory resets but the file name stays, producing a broken hybrid of the two paths.
Ultimately, I discovered that even though you call it 'dbPath' and set the whole path using a single UI element, the internal logic parses out the directory part, calls it Database, and stores it in a per-user registry key at HKCU\Aquila Technology. Then, when loading user.config, dbPath is parsed for the filename, while the directory path is taken from the registry. The merged path is then written back to the config file.
Or at least, that's my best guess as to what's going on. It is likely that part of this behavior is intended, and that I'm tripping up on the strangely complex and fragile way the database path handling is implemented.
That's right, it backs up the data in the registry. I can't remember but I think that was to be able to make it seamless to do online updates.
The folders created in the GAC are Microsoft doing that. That's how DotNET stores application data. What are you trying to accomplish? Manually editing the GAC is possible but probably not a good idea.
Simple, I'm trying to give each user their own individual machines.xml file, each placed in their own user profile. And I need to be able to do this without logging in as them and clicking through the UI every single time.
This is not a dontet issue, this is caused by the (strange?) way you are handling the paths. I checked the code, and I am guessing that the reason 2.11.15 'worked' for me was missing checks that were added later in 1a7ad6ef. Trying to access the nonexistent registry key would raise a silent exception and prevent the remainder of the function from executing, thus leaving the settings data intact.
So technically, the thing is now working correctly. The name 'dbPath' is a bit misleading; at runtime, it indeed is the full path, however on disk it effectively acts as dbFileName due to how MyApplication::upgradeSettings() behaves at startup. It is not clear to me why the registry is used at all for this, the code itself was added in 6cfb4c00 "add option to setup to specify the database folder". So maybe you had no other way to interface with setup... but then shouldn't this only have been a one-time first-run kind of thing? Unless maybe you also needed it to be remembered across setups, so that it would always show the latest path. I'm still unsure if this is how it's supposed to be, but I'm not familiar with the code and setup workflow enough to suggest alternatives.
The reason is that InnoSetup, which is used as the installer and updater, has no concept of the application settings. So, to make a seamless update for the average user, some key elements are back-stored in the registry so that they can be restored once the innosetup has updated them.
Yup, something like that. So right now, the user.config file is not intended to be directly editable, and right now such modifications are not supported (although editing anything but the dbPath seems fine). But at least now I am aware of what's going on and can work around it.
One possible way to maybe change this would be to not have the registry Database directory be the authoritative location for this setting. Instead, only use it during the first-time installation step, and only if user.config does not yet exist. But I checked your installer, and there don't seem to be any references to this registry key, or database path?
Correct about the installer, it doesn't know or care about the user's settings. It's been so long now the exact reasoning for this eludes me. But I remember that doing an in-place update would cause users to lose their config settings. So this hack was to prevent that... I sadly have no time for the project anymore - work is an extreme crush right now. So many things I would like to change if I had the time.