Overrides from Outset 3 do not get migrated to /Library/Preferences

[jazzace]

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

1. Install Outset 3 (final Python version).
2. Add a script with executable privileges to the login-once folder.
3. Add an override for that file using the --add-override option.
4. Install Outset 4.
5. Reboot.
6. Login to any account.

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:

• OS: macOS 13.6.3
• Architecture: only tested on Intel
• Version: 4.1.1.21918

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.

[bartreardon]

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 /usr/local/outset/share/com.chilcote.outset.plist over to /Library/Preferences/io.macadmins.Outset.plist.

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 ( /Library/Preferences/io.macadmins.Outset.plist is effectively "all users") so limiting this to happen only when root is process owner should suffice. the migrateLegacyPreferences() function runs whenever there are items to process.

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.

[jazzace]

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.

[bartreardon]

hmm.

The only file that will get cleaned up at a user level is ~/Library/Preferences/com.github.outset.once.plist This gets cleaned up in the same step as the root level com.github.outset.once.(userID).plist so you'll see a message in the log that both of those things are going to happen. if the process is running as the user, only the user file is cleaned. if the process is running as root only the root level file is cleaned. Outset will need to run once as the user and once as root (usually at boot or a login-priviledged) for both files to be migrated and cleaned. Until that happens, settings in the root level file won't apply to the user.

I can document that it should migrate everything over but verification of overrides might be a good idea.

[jazzace]

When do we ever run Outset as root? Login-privileged-once perhaps?

[bartreardon]

It runs on boot and at the login window as well as privileged

[jazzace]

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?

[bartreardon]

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.

[jazzace]

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.

[bartreardon]

seems the fix for this was merged in April but the issue never closed off. Will close for now but if it's still a thing, please re-open