[GH-ISSUE #1419] Symlinked preferences (.plist) is reset automatically #804

New issue

Closed

opened 2026-05-05 06:43:40 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 06:43:40 -06:00

Owner

Originally created by @wohfab on GitHub (Aug 31, 2023).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1419

Before opening the issue, have you...?

Searched for existing issues
Looked through the wiki
Updated MonitorControl to the latest version (if applicable)

Describe the bug

I am using mackup (https://github.com/lra/mackup) to backup my .dotfiles including preferences and settings of installed apps. The program works the way, that it duplicates the original preference files from the ~/Library/ directories to a specified directory and then create a symlink to this file back into the directory. For MonitorControl it takes these steps:

Duplicate ~/Library/Preferences/me.guillaumeb.MonitorControl.plist into ~/.dotfiles
Delete original ~/Library/Preferences/me.guillaumeb.MonitorControl.plist
Symlink ~/.dotfiles/me.guillaumeb.MonitorControl.plist back to ~/Library/Preferences/me.guillaumeb.MonitorControl.plist

MonitorControl however deletes this symlink and recreates the preferences automatically with the same filename but with the symlink stripped from it. This way mackup throws an error and-more important-does not backup the preferences for MonitorControl.

Steps to reproduce

Install mackup via brew install mackup
Create config file for monitorcontrol (following the docs) at ~/.mackup/monitorcontrol.cfg with

[application]
name = MonitorControl

[configuration_files]
Library/Preferences/me.guillaumeb.MonitorControl.plist

Run backup via mackup backup
Symlink is created and the shortly after removed again and replaced by the original file without symlink

Expected behavior

Option: Change content of .plist file without recreating it every time
Option: When recreating .plist file, keep symlink status intact

Anything else?

I know, this is not per se a bug with MonitorControl; more an unexpected behaviour with the .plist file. If this is better suited as a discussion post, please feel free to move it over. Thanks a lot for your consideration!

Environment Information (please complete the following information)

- macOS version: 14.0 Sonoma
- Mac model: Macbook Pro, M1 Pro
- MonitorControl version: v4.1.0 Build 7034 (installed via Homebrew)
- Monitor(s): -
- Apple Silicon/M1: yes

Originally created by @wohfab on GitHub (Aug 31, 2023). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1419 ### Before opening the issue, have you...? - [X] Searched for existing issues - [X] Looked through [the wiki](https://github.com/MonitorControl/MonitorControl/wiki) - [X] Updated MonitorControl to the latest version (if applicable) ### Describe the bug I am using `mackup` (https://github.com/lra/mackup) to backup my `.dotfiles` including preferences and settings of installed apps. The program works the way, that it duplicates the original preference files from the `~/Library/` directories to a specified directory and then create a symlink to this file back into the directory. For MonitorControl it takes these steps: 1. Duplicate `~/Library/Preferences/me.guillaumeb.MonitorControl.plist` into `~/.dotfiles` 2. Delete original `~/Library/Preferences/me.guillaumeb.MonitorControl.plist` 3. Symlink `~/.dotfiles/me.guillaumeb.MonitorControl.plist` back to `~/Library/Preferences/me.guillaumeb.MonitorControl.plist` MonitorControl however deletes this symlink and recreates the preferences automatically with the same filename but with the symlink stripped from it. This way `mackup` throws an error and-more important-does not backup the preferences for MonitorControl. ### Steps to reproduce 1. Install `mackup` via `brew install mackup` 2. Create config file for `monitorcontrol` ([following the docs](https://github.com/lra/mackup/tree/master/doc#add-support-for-an-application-or-almost-any-file-or-directory)) at `~/.mackup/monitorcontrol.cfg` with ``` [application] name = MonitorControl [configuration_files] Library/Preferences/me.guillaumeb.MonitorControl.plist ``` 3. Run backup via `mackup backup` 4. Symlink is created and the shortly after removed again and replaced by the original file without symlink ### Expected behavior 1. Option: Change content of `.plist` file without recreating it every time 2. Option: When recreating `.plist` file, keep symlink status intact ### Anything else? I know, this is not per se a bug with MonitorControl; more an unexpected behaviour with the `.plist` file. If this is better suited as a discussion post, please feel free to move it over. Thanks a lot for your consideration! ### Environment Information (please complete the following information) ```markdown - macOS version: 14.0 Sonoma - Mac model: Macbook Pro, M1 Pro - MonitorControl version: v4.1.0 Build 7034 (installed via Homebrew) - Monitor(s): - - Apple Silicon/M1: yes ```

gitea-mirror closed this issue

2026-05-05 06:43:41 -06:00

gitea-mirror commented

2026-05-05 06:43:44 -06:00

Author

Owner

@waydabber commented on GitHub (Sep 10, 2023):

MonitorControl is managing userdefaults via the normal system calls only so I am not sure what to do with this, but will leave it open, maybe somebody has an idea. :)

@waydabber commented on GitHub (Sep 10, 2023): MonitorControl is managing userdefaults via the normal system calls only so I am not sure what to do with this, but will leave it open, maybe somebody has an idea. :)

gitea-mirror commented

2026-05-05 06:43:46 -06:00

Author

Owner

@olssonm commented on GitHub (Oct 1, 2023):

@wohfab Found this thread via Google. This doesn't seem to have anything to do with MonitorControl or the apps themselves, but rather how macOS Sonoma (and perhaps even latest Ventura) handles symlinks for plists and the like (broken). Many apps via Mackup are currently experiencing major issues. See https://github.com/lra/mackup/issues/1924

@olssonm commented on GitHub (Oct 1, 2023): @wohfab Found this thread via Google. This doesn't seem to have anything to do with MonitorControl or the apps themselves, but rather how macOS Sonoma (and perhaps even latest Ventura) handles symlinks for plists and the like (broken). Many apps via Mackup are currently experiencing major issues. See https://github.com/lra/mackup/issues/1924

gitea-mirror commented

2026-05-05 06:43:48 -06:00

Author

Owner

@wohfab commented on GitHub (Oct 1, 2023):

See https://github.com/lra/mackup/issues/1924

Oh, this is really good to know! Thanks for that link, @olssonm! I guess it's time to pause mackup for a while and see how fast this can be solved.

@wohfab commented on GitHub (Oct 1, 2023): > See https://github.com/lra/mackup/issues/1924 Oh, this is really good to know! Thanks for that link, @olssonm! I guess it's time to pause mackup for a while and see how fast this can be solved.