-
Notifications
You must be signed in to change notification settings - Fork 12
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
Overrides from Outset 3 do not get migrated to /Library/Preferences #50
Comments
So I think this is a case of a race condition. When outset 4 is installed it should run through the migration process at a root level and this should migrate all I'm pretty confident that any data in the old plist doesn't need to be stored in the users plist explicitly due to how userdefaults operates ( This is still not 100% perfect as there may be opportunity for an override in the old preferences that should apply but won't if the the old preferences file exists in between a root process running outset and a user process, but at least it won't try to migrate and delete when it has no permissions to delete the old file. |
The good news: the error condition no longer shows up in the logs. The bad news: It still tries to migrate the Outset Python overrides every login, they never get migrated to /Library/Preferences, and thus the old Outset Python overrides are never removed. I actually think this might be a semantic error, as the overrides get stored in ~/Library/Preferences after trying the conversion, but since the overrides are to apply to all users, they should be stored in the root /Library/Preferences folder instead. Again, I'm fine if you just document that overrides need to be re-established on conversion if it is too much work. |
hmm. The only file that will get cleaned up at a user level is I can document that it should migrate everything over but verification of overrides might be a good idea. |
When do we ever run Outset as root? |
It runs on boot and at the login window as well as privileged |
Good to know. Yet it still doesn't ever move the overrides to /Library/Preferences. Is it because I only have items in login-once and login-every? |
If they are user only settings they will end up in that users preference file. Theres not quite a 1:1 match with how old prefs were stored vs how userdefaults can read things in so its a bit of a juggle. It should however appear to read in the right the right context. If its not doing that then i can tweak it a bit, or just document it in a way that suggests we have a decent crack at migration but it might not be 100% depending on the complexity of your environment. I wouldnt mind at least trying to get it right though. |
I am definitely looking for the same behaviour as we generally get with Preferences when running an app (/Library/Preferences applies to all users, ~/Library/Preferences only applies to that user). I think that's the only way overrides would work properly — the date of the update is global and is not user-specific. |
Describe the bug
Outset attempts to migrate settings from Outset 3 (Python). If overrides are present in /usr/local/outset/share/com.chilcote.outset.plist, they are loaded correctly but are not saved to /Library/Preferences/io.macadmins.Outset.plist. This appears to be because the migration is triggered when Outset is running in a user context and thus does not have permission to write to /Library/Preferences. An error is reported that
/usr/local/outset/share/com.chilcote.outset.plist could not be removed
.To Reproduce
--add-override
option.Expected behaviour
Overrides are migrated and stored in /Library/Preferences/io.macadmins.Outset.plist. The preferences from Outset 3 are deleted.
Actual behaviour
Overrides are loaded upon login and stored in ~/Library/Preferences/io.macadmins.Outset.plist. Outset attempts to delete the preferences from Outset 3 but fails, reporting
ERROR: /usr/local/outset/share/com.chilcote.outset.plist could not be removed
. Because the preferences from Outset 3 are not deleted, the migration is attempted again on next login (to any account). This has the positive side effect of enforcing the override, since it gets loaded and saved to user-space settings, but it never goes away.System Details:
Additional suggestion
It may not be worth the effort to fix this bug, since recreating the overrides in Outset 4 works and the number of Outset 3 holdouts (or even users who know how to use overrides) is not known. Documenting the fact that settings with overrides need to be manually migrated and old preferences manually deleted may be sufficient.
The text was updated successfully, but these errors were encountered: