Implement a Mackup copy feature, breaking the historical behavior of Mackup?

[lra]

I have more and more requests asking me to implement a "copy" behavior in Mackup: Instead of linking configuration files in a shared folder used by multiple computers, it would copy config files on demand from and to this shared folder.

This is the current UX:

• mackup backup moves local config file in remote folder, and links them
• mackup restore links local config file from the remote folder
• mackup uninstall removes the links and copy config files from the remote folder locally

This is what I envision:

• mackup link install moves local config file in remote folder, and links them
• mackup link links local config file from the remote folder
• mackup link uninstall removes the links and copy config files from the remote folder locally
• mackup backup copy local config files in the configured remote folder
• mackup restore copy config files from the configured remote folder locally
• mackup prune remove remote files that are not present locally anymore

This would break current Mackup behavior, but I would bump the version to v0.9 and state the breaking change in the changelog.

This would also allow the glob pattern for config files in a future release.

Any better suggestion?

[ahmadawais]

Would be great to keep backward compatibility and introduce a new command like mackup sync which only copies the files to a backup folder and does no linking.

[castus]

AFAIK, this is what the new mackup backup will do.

[castus]

[A feature request, connected to the new copy behavior.]
Copying files over and over would lead to some mess in the remote folder. As a mitigation, we can create mackup prune to remove remote files that are not present locally anymore. Wdyt?

[lra]

Good idea, added in the original post. Thanks!

[owpac]

Hey there!
I would like to suggest a different approach related to the new copy behavior.
Today, this is a configuration file for mackup:

[storage]
engine = file_system
path = Backup
directory =

[applications_to_sync]
raycast
iterm2

My suggestion is a new configuration file with something like this:

[storage]
engine = file_system
path = Backup
directory =

[applications_to_sync_links]
raycast

[applications_to_sync_copy]
iterm2

With this proposal, you can have more flexibility and have both of the two worlds depending on your needs. It would also be possible to keep the current commands.

Another possibility could be to add a flag --file to the new proposed commands to describe a different list of apps to handle depending on the needs. E.g.:

mackup link --file /path/to/mackup.cfg
mackup backup --file  /path/to/other_mackup.cfg

What do you think?

[lra]

Could be useful, but not for the MVP of copy feature, or it will never get out.

[1activegeek]

Reviewing the proposed change - I'd actually suggest creating a NEW command for the new behavior (such as your mackup link install) and leave the old behavior. Not that it will help or affect me specifically, but for those folks out there making no changes to their current setup and using older versions - no impact. Introducing the change, marking it as breaking, and then also adjusting the documentation to sub in the NEW command as the default for everything - will ensure nobody is broken by the change.

Just my 2 cents as a lower friction overall approach. Since anyone who is currently broken, likely already stopped syncing the old way - it's a small chance that people affected are leaving all their commands, scripts, and plans in place without needing adjustment anyhow. Why not just introduce new commands and simplify.

As I wrote this, I also was thinking, maybe you just create new verbs entirely to reduce how many extra parameters/words exist? Perhaps something like:

• mackup copy or mackup deploy
• mackup download or mackup replicate
• mackup cleanup or mackup prune

Leaves room to leave the original commands intact, reduce your code changes, remove friction for any current user without this issue, and allows for simply updating the core documentation to make folks aware of the 2 paths of deployment.

[lra]

That's the 2nd proposal. It might be useful for you but the terms are confusing, that's why I proposed the breaking change (1st proposal).

[NamekMaster]

For the new feature, how about keep monitoring the config files and back up them automatically when anything changes?

[lra]

This is asking to implement a file cloud service, and would require a daemon to constantly check those files. Instead, Mackup let you pick and leverage the file cloud service, or not.

[NamekMaster]

So, what is the time to run the new command? Without symbolic link the content cannot keep consistent all the time, but if I need to run command manually each time, it's not convenient.

[lra]

Whenever they want to, up to them.

[brandon-fryslie]

@NamekMaster if you run man cron in your terminal, there is a ready made solution built right into MacOS. If it's not clear after reading that page, ask ChatGPT and I'm confident it will help you find a good solution.

[lra]

Looks like this is settled.

[Wxh16144]

I noticed that the current discussion status is in Closed, has this been implemented, but I don't seem to have seen any updates on the documentation.

[lra]

No, this decision is settled, the code is not implemented yet.

[maxhoheiser]

any updates on the timeline, since this would solve the issue with macos 14 not allowing symlinks for security reasons for a majority of apps: #1924

[Wxh16144]

Hmm, thank you, I don't have the motivation to learn Python, otherwise I would be happy to contribute.

[stereokai]

This is amazing. Highly looking forward!

[halilim]

To emphasize an important point: with mackup backup copying instead of linking, the responsibility of keeping the backups up to date is now on users' shoulders.

[evanharmon1]

If we switch to the new copy files to remote
method, would that not cause issues when using multiple Macs? Ie, it would require pruning to remove no longer used local files but then you couldn't rely on that logic if you have another Mac in the mix that may still need those unused files...

[spuder]

Since this would be a breaking change, a 1.0 release would be more appropriate than 0.9

I would rather see mackup backup and mackup restore commands be deprecated to minimize surprises for the people who have auto-updates turned on.