Keeping 2 Macs Synchronized

Updated 7/28/2008 3:00 AM. (Corrected errors and added Unison)

When my new iMac was up and running smoothly I turned my focus to keeping it synced with my Macbook Pro. This turned out to be a rather challenging and complicated task. Mac OS X normally uses the HFS+ file system which adds extended attributes and resource forks. Most open source command-line utilities do not play well with those two additions, including some of Apple’s own ports. I spent many hours researching and testing various applications and thought I would share my findings and thoughts.

rsync

I use rsync quite frequently when transferring files to and from my server so it was my first choice.

Viable: No. Apple’s port (2.6.3) does not handle extended attributes properly but the latest development version of rsync (3.0.3pre3) does.
Resources:
Other Thoughts: Although rsync works perfectly there are a couple of problems. The biggest of which is that it is a unidirectional sync tool. It is not designed to perform any kind of n-way synchronization. Although the transfer algorithms are fast, handling extended attributes dramatically impacts scanning performance.

Unison

Unison employs similar algorithms to rsync but is designed around bidirectional synchronization

Viable: No. While Unison does handle resource forks, it does not handle extended attributes.
Resources:
Other Thoughts: Scanning and comparing files seems slower than rsync.

Subversion

The idea of having my entire home directory under subversion control is very appealing. Rolling backups would be taken care of in a more efficient manner than Time Machine and conflicts when syncing would be handled gracefully.

Viable: Maybe. All of the versioning systems that I looked at do not handle extended attributes properly. That includes SVN and Git. But there is an extension that you can compile that will run on top of Git to enable handling of xattr called gibak.
Resources:
Other Thoughts: I’m trying to hold off on this because of the increased space requirements. Additionally, I don’t really need my life under version control. Last of all, my meta information is located in one precious and fallible dot file. But I’m still holding this option in reserve.

And so with the failure of the most prominent solutions I had to turn to commercial software.

ChronoSync

Viable: Yes. It appears to preserve dates and times.
Resources:
Other Thoughts: Unlike Synk (see below) ChronoSync will treat packages as directories if you tell it to. Unfortunately you must perform a scan on every transfer which takes time.

Synk Proffesional

Viable: Yes. It properly handles extended attributes and the created date but not the modified date in my tests.
Resources:
Other Thoughts: Although it meets the core requirements and is viable it fails my requirements. It treats packages as a whole instead of as a directory (and no delta compression) so if you have a 50MB OmniFocus package the entire thing must be transferred again. The same goes for normal files, there’s no rsync-like algorithm here. Attempting to quickly sync my OmniFocus library over the network on my way out the door would be unnacceptably long.

In conclusion there are no solutions that meet my criteria for a proper 2-way sync on the Mac platform. Keep an eye out for my follow up posts because I am determined to find a solution to this problem.

2 comments… add one
  • mfv Nov 6, 2009

    didn’t you try “Synchronize! Pro X” ?

    • Jon Stacey Nov 8, 2009

      @mfv, It’s been awhile, but I believe that I did look into it and found it somewhat similar to ChronoSync. Unfortunately, neither use delta encoding to reduce what must be transferred over the network and that is one of my requirements.

      I’ve been using Dropbox for the past year with success–I’m just very careful about what files I put in there with the understanding that metadata will be lost. This looks like it will be improving sometime in the next few months: http://forums.dropbox.com/topic.php?id=14072&replies=5#post-87707

Leave a Comment

Time limit is exhausted. Please reload CAPTCHA.