For the past 3.5 yrs I’ve been using Unison to sync files between 3 macs. It works great. In fact, since I installed and set up my profiles for syncing, I’ve not needed to change a thing. Until yesterday.
I upgraded to El Capitan on each of the 3 macs.
I went to run Unison to sync the days work and – an error.
-bash: unison: command not found
Oh dear. I looked in the search path and couldn’t find Unison. My guess is that it got erased during the upgrade (not sure what the problem is). So I re-installed, no big deal. Let’s face it, Unison has changed in those 3.5 years, so I’ll be getting the latest version.
You can get a nice compiled version from @alan_schmitt here. Version 2.48.15 runs on El Capitan. I always run Unison from the command line, but those tools can be installed from this GUI version.
I did this for all 3 macs and checked that Unison was installed by typing
unison -version
All good. I then ran each profile and… command not found. I realised that via ssh, the search path is not the same as via bash. Long story short. I added the following to my profile.
servercmd=/usr/local/bin/unison
Thank you to @alan_schmitt for the suggestion. This is actually a solution that is specified in the documentation. I thought I’d write this down in case it helps anybody.
Now my profile (syncimac.prf) looks like this
servercmd=/usr/local/bin/unison root = /Users/name/Documents/ root = ssh://name@computername.home//Users/name/Documents/ times = true log = false ignore = Name .FBCIndex ignore = Name .FBCLockFolder ignore = Name {Cache*,.Trash*,.VolumeIcon.icns,.HSicon,Temporary*,.Temporary*,TheFindByContentFolder} ignore = Name {TheVolumeSettingsFolder,.Metadata,.filler,.idsff,.Spotlight,.DS_Store,.CFUserTextEncoding} ignore = Name .localized ignore = Name .fseventsd ignore = Path .unison
this is saved in ~/.unison/ and I invoke it by running
unison syncimac -ui text
On the first run it detected a Unicode change which I think is due to the new version of Unison. So I needed to ignore the old archives with the flag -ignorearchives. Then it’s fine to run again.
—
The post title is taken from “Super Unison” by Drive Like Jehu from their LP Yank Crime
Helped me! Thank you for sharing!
Cool. Thanks for the comment.
That was the missing bit… Thanks!
any else able to get fsmonitor.py working in el capitan? (not me.)
I was able to get the newer unison-fsmonitor working though.
What do you mean newer version? which version is that?
2.48.15
As I said in the post the version I was running was nearly 4 years old.
Edit: sorry, you were asking about fsmonitor. My mistake.
Thank you!
Two comments on this post today reminded me to post this link to Alan’s distros
http://unison-binaries.inria.fr
Thanks to Christophe for the tip.
@Neal I don’t use fsmonitor so can’t help sorry.
Another update on Unison use for more than two computers. In the manual it says:
‘If you need to do this, the most reliable way to set things up is to organize the machines into a “star topology,” with one machine designated as the “hub” and the rest as “spokes,” and with each spoke machine synchronizing only with the hub. The big advantage of the star topology is that it eliminates the possibility of confusing “spurious conflicts” arising from the fact that a separate archive is maintained by Unison for every pair of hosts that it synchronizes.’
My experience is:
1. invoking Unison from each spoke machine causes confusion, so having profiles for each computer you want to synchronise on the hub machine and invoking each script in turn on the hub machine is by far more reliable.
2. only invoke one way, don’t switch around.
3. think about which is your slowest connection and build around this, e.g. if one machine is remote, contacted via the internet, maybe via VPN; this will be slower than on your LAN.
Four machines A,B,C,D. Where A is the hub.
This works:
A->B, A->C, A->D
This causes conflicts:
B->A, C->A, D->A.
As does this:
A->B, C->A, D->A.
This works
A->B, B->C, A->D; as long as the pairs are consistently used and A and C are not synced.
Note that Unison will sync all of these scenarios and do it properly, it’s just that you will have numerous spurious conflicts where Unison is not sure what to do, or Unison will get confused over which archive to use.
One issue that cropped up using Unison is that my local host name started to change when using VPN to access the remote network. This meant that Unison didn’t recognise the old archive and had to make a fresh one each time. Apart from taking longer, this leads to problems with the sync (e.g. files that have been deleted on one machine being put back on from the other). Unison tells me that you can overcome this by setting the environment variable UNISONLOCALHOSTNAME. Googling didn’t quite reveal how to do this so I’m leaving this comment. In the terminal, before executing the Unison command, execute
export UNISONLOCALHOSTNAME=mymachine
now execute the Unison command to your profile file
unison myprofilefile -ui text
Obviously mymachine can be whatever you want, but it just needs to be consistent between syncs.
Hope this helps somebody.
A further comment on Unison usage. I found over the past few months that .ai files (Adobe Illustrator files) were not syncing correctly. I was working around this by using DropBox or zipping the files before syncing, but something was clearly not right. I was using 2.48.15 on High Sierra and it seems that Apple’s move to AFPS screwed with the ability to sync ai files. I couldn’t find an update, but Christophe just pointed me to a version release of Unison on GitHub.
https://github.com/bcpierce00/unison/releases
This version (2.51.2) works with ai files from the command line (after installing command line tools from the Unison GUI).