Got this when trying to backup my .atom folder :

Traceback (most recent call last):
  File "/usr/local/bin/mackup", line 26, in <module>
    mackup.main.main()
  File "/usr/local/Cellar/mackup/0.7.2/lib/python2.7/site-packages/mackup/main.py", line 48, in main
    app.backup()
  File "/usr/local/Cellar/mackup/0.7.2/lib/python2.7/site-packages/mackup/application.py", line 83, in backup
    utils.copy(filepath, mackup_filepath)
  File "/usr/local/Cellar/mackup/0.7.2/lib/python2.7/site-packages/mackup/utils.py", line 91, in copy
    shutil.copytree(src, dst)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 208, in copytree
    raise Error, errors
shutil.Error: [('/Users/anahkiasen/.atom/packages/emmet/node_modules/.bin/csonc', '/Users/anahkiasen/Dropbox/Mackup/.atom/packages/emmet/node_modules/.bin/csonc', "[Errno 2] No such file or directory: '/Users/anahkiasen/.atom/packages/emmet/node_modules/.bin/csonc'"), ('/Users/anahkiasen/.atom/packages/emmet/node_modules/season/node_modules/.bin/cake', '/Users/anahkiasen/Dropbox/Mackup/.atom/packages/emmet/node_modules/season/node_modules/.bin/cake', "[Errno 2] No such file or directory: '/Users/anahkiasen/.atom/packages/emmet/node_modules/season/node_modules/.bin/cake'"), ('/Users/anahkiasen/.atom/packages/emmet/node_modules/season/node_modules/.bin/coffee', '/Users/anahkiasen/Dropbox/Mackup/.atom/packages/emmet/node_modules/season/node_modules/.bin/coffee', "[Errno 2] No such file or directory: '/Users/anahkiasen/.atom/packages/emmet/node_modules/season/node_modules/.bin/coffee'"), ('/Users/anahkiasen/.atom/packages/emmet/node_modules/season/node_modules/fs-plus/node_modules/.bin/rimraf', '/Users/anahkiasen/Dropbox/Mackup/.atom/packages/emmet/node_modules/season/node_modules/fs-plus/node_modules/.bin/rimraf', "[Errno 2] No such file or directory: '/Users/anahkiasen/.atom/packages/emmet/node_modules/season/node_modules/fs-plus/node_modules/.bin/rimraf'"), ('/Users/anahkiasen/.atom/packages/travis-ci-status/node_modules/.bin/travis-ci', '/Users/anahkiasen/Dropbox/Mackup/.atom/packages/travis-ci-status/node_modules/.bin/travis-ci', "[Errno 2] No such file or directory: '/Users/anahkiasen/.atom/packages/travis-ci-status/node_modules/.bin/travis-ci'")]

If ~/.mackup.cfg does not exist, Mackup asks the user if he wants to make one. It then prompts them to answer some questions so that it can be generated. Also generates custom apps in the ~/.mackup folder if the user wants to.

Mavericks uses cfprefsd deamon to cache app settings. This caused mackup not to work for many apps (for example Forklift, F.lux) and even worse, to delete settings.

http://www.macinside.info/process.php?id=6616

Steps to reproduce:

1. Login in both computers
2. Open Forklift (for example, can be any app with a plist file in ~/Library/Preferences/) in both computers.
3. Quit Forklift in both computers.
4. On computer #1, change a setting for the app, close the app, and wait for dropbox to sync the file to the second computer.
5. On computer #2, open forklift. You will notice the app doesn't reflect your change.
6. Close the app. The plist file will get overwritten with the settings that are on computer #2, therefore deleting the setting you've set on step 3.

I've tried disabling the cfprefsd service, however, this prevents the mac from loading any plist file.

Mac App Store apps keep files inside ~/Library/Containers/. These cannot be replaced with soft links (ln -s), but do work with hard links (ln) and OS X aliases. Since hard links cannot be used on directories, this would work for many apps, but not all.

My suggestion would be to add CONTAINERS = 'Library/Containers/' to # Commonly used paths #, and then when mackup encounters an app that references something that starts with CONTAINERS, use the applescript way; else, make a symbolic link as always.

I’ve been thinking about this option lately. I’ve personally had my fair share of issues caused by the way mackup works by default (making links to a dropbox directory), whether by having more than one computer logged on at the same time, changes to mackup itself, or some other reason. I’ve also seen some other open issues with problems that would not occur would it not be for settings being symlinked, as opposed to copied over.

How many times do users change app settings, really? Wouldn’t the extra (small) trouble of running a command when updating settings be a more than acceptable price to pay for improved stability? It would also provide some features for free, like support for MAS apps.

Now, I certainly understand that would be a big change to this tool (that a lot of people use), so I’m looking for your input on this, @lra, is this something you’d be willing to consider?

I'm using the iCould engine, no other configuration.

After running mackup backup -f, the ~/.oh-my-zsh is left in a dirty state, which breaks upgrade_oh_my_zsh.

➜  .oh-my-zsh git:(master) ✗ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    custom/example.zsh
	deleted:    custom/plugins/example/example.plugin.zsh
	deleted:    custom/themes/example.zsh-theme

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	custom

no changes added to commit (use "git add" and/or "git commit -a")

➜  ~ upgrade_oh_my_zsh
Updating Oh My Zsh
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.
There was an error updating. Try again later?

Today I was using Mackup and I noticed this in the help documentation:

By default, Mackup syncs all application data (including private keys!) via Dropbox, but may be configured to exclude applications or use a different backend with a .mackup.cfg file.

I really like Mackup—it saves a ton of time when setting up a new computer. However, the idea of automatically syncing SSH keys by default really scares me. A few years ago I accidentally exposed an SSH key and someone used it to charge a few thousand dollars to AWS for my company. I'd really like to avoid doing anything like this again in the future.

In reading through #512 and #109, it looks like this behavior was turned off. However, the help documentation doesn't seem to indicate that. So which one is correct? I feel strongly that synching private keys by default is not obvious behavior, and it has the potential to have some serious consequences.

Also, will Mackup sync other types of sensitive information in the future? What scares me most about this is not necessarily what Mackup is syncing today, but what it might add in the future that I don't notice.

Thanks!

I have backup on Dropbox one day ago, and config with ~/.mackup.cfg but today use mackup restore and get error on new mac.

error message:

$ mackup restore
Traceback (most recent call last):
  File "/usr/local/Cellar/mackup/0.8.1/libexec/bin/mackup", line 9, in <module>
    load_entry_point('mackup==0.8.1', 'console_scripts', 'mackup')()
  File "/usr/local/Cellar/mackup/0.8.1/libexec/lib/python2.7/site-packages/mackup/main.py", line 59, in main
    mackup_app.restore()
  File "/usr/local/Cellar/mackup/0.8.1/libexec/lib/python2.7/site-packages/mackup/application.py", line 122, in restore
    home_filepath))
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 162, in samefile
    s1 = os.stat(f1)
OSError: [Errno 2] No such file or directory: '/Users/amowu/Dropbox/Mackup/.mackup.cfg'

why the .mackup.cfg change to Dropbox folder?

thanks.

It is safer to prevent any the credential keys shared or backed up. Normally if computer changed, the user should generate new keys instead of reusing existing ones.

After upgrading mackup to 0.7.4 via homebrew, it became impossible to use the executable as it immediately coughed and died.

The cough:

$ mackup
Traceback (most recent call last):
  File "/usr/local/bin/mackup", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2603, in <module>
    working_set.require(__requires__)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 666, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 565, in resolve
    raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: mackup==0.7.4

About my current setup:

$ uname -a
Darwin Concurrent-Chickpea.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

$ brew --version
0.9.5

If I can provide any additional info, please let me know.

Thanks!

• Jonathan

Backing up Library/Application Support/SourceTree/sourcetree.license...
Traceback (most recent call last):
  File "./mackup.py", line 731, in <module>
    main()
  File "./mackup.py", line 684, in main
    app.backup()
  File "./mackup.py", line 310, in backup
    delete(filepath)
  File "./mackup.py", line 490, in delete
    os.remove(filepath)
OSError: [Errno 1] Operation not permitted: '/Users/dbingham/Library/Application Support/SourceTree/sourcetree.license'

All submissions

• [x] I have followed the Contributing Guidelines
• [x] I have checked to ensure there aren't other open Pull Requests for the same update/change

Adding/updating Application X Support

• [ ] This PR is only for one application
• [x] It has been added to the list of supported applications in the README
• [x] Changes have been added to the WIP section of the CHANGELOG
• [x] Syncing does not break the application
• [x] Syncing does not compete with any syncing functionality internal to the application
• [x] The configuration syncs the minimal set of data
• [x] No file specific to the local workstation is synced
• [x] No sensitive data is synced

Improving the Mackup codebase

• [x] My submission passes the tests
• [x] I have linted the code locally prior to submission
• [ ] I have written new tests as applicable
• [ ] I have added an explanation of what the changes do

Bumps certifi from 2021.10.8 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I find it quite indirect when trying to desync a single synced application. I have to manually copy back the file(s) and modify the config. It would be convenient by adding CLI options like mackup sync <application> and mackup desync <application> to automatically get the works done.

wondering if it's just me. i remember the first time i played with mackup i tried both iCloud and Dropbox and i had issue with iCloud where some plist wouldn't be read or recognized by some apps. switching to Dropbox solved this issue.

now Dropbox has updated its macOS integration by moving to the /Library/CloudStorage folder. things start breaking again for me. i'm not talking about symlink issues, my symlinks are correctly updated. but for example (at least) Xcode doesn't seem to be able to read/write its general plist from the Dropbox folder. each time i start it, all my settings are back to zero. if i remove the symlink and copy the plist file instead, it works. Xcode reads it and all my settings are back. as soon as i use again a symlink though, it seems Xcode doesn't "get" it.

so, wondering. is it me? is it the switch to the /Library/CloudStorage from Dropbox? if it's not just me, i guess there's something to be updated on mackup's side, even if it's just the support for Xcode overall, and the xcode.cfg.

Hi There

I use Mackup with dropbox (using CloudStorage) using the workaround suggested in #1858 - I am running on an M1 Pro MBP but i can also observe the same issue on an Intel Mac as well

this might be happening in more apps, i've noticed a few apps (Apple native and non Apple)

I prefer to use a different Shell profile and fonts etc, wierd that after upgrade (reinstall and restore mackup) - my terminal preferences were back at default

attempted to manually change the preferences in terminal, when i quit it and restarted it, it was back to default.

deleted the Symlink to terminal preferences -

rm ~/Library/Preferences/com.apple.Terminal.plist

restarted terminal, reset settings, restarted terminal and the settings are fine

is there possibly some new permissions/security change that breaks symlinks and therefore mackups functionality on ventura?

I've observed similar issues in iStat Menus, need to check for other apps specifically

shell or other command line based utilities appear to be OK, it does appear to be limited to "GUI" apps at a first glance

Summary:

• Adding missing karabiner config
• Missing Postico data
• Missing .config folder and app support for raycast
• Include entire dash app support, includes some seemingly-important library files

Some of the changes are a bit liberal with including data that could contain sensitive data or state-dependend information. However, I've found this is better than the alternative in my case.

All submissions

• [ ] I have followed the Contributing Guidelines
• [ ] I have checked to ensure there aren't other open Pull Requests for the same update/change

Adding/updating Application X Support

• [ ] This PR is only for one application
• [ ] It has been added to the list of supported applications in the README
• [ ] Changes have been added to the WIP section of the CHANGELOG
• [ ] Syncing does not break the application
• [ ] Syncing does not compete with any syncing functionality internal to the application
• [ ] The configuration syncs the minimal set of data
• [ ] No file specific to the local workstation is synced
• [ ] No sensitive data is synced

Improving the Mackup codebase

• [ ] My submission passes the tests
• [ ] I have linted the code locally prior to submission
• [ ] I have written new tests as applicable
• [ ] I have added an explanation of what the changes do