How does syncthing differ from rsync and unison? What does it bring that these two protocols do not have?
I interpret this as a bug report that our homepage doesn’t adequately explain what it is we do exactly. Which is true, it hasn’t really been updated in almost two years…
As to the actual question… It’s different. Try it. Or not, if rsync or unison does what you need.
1 Like
rsync is a tool for making a copy. It mirrors files from one place to another, in one direction only.
unison is basically like rsync except it goes both ways. It copies in both directions at once and tries to merge the changes from both sides. Imagine you had an extra copy of your music library on a computer at work. You add one song at home, and a different song while at work. You could use unison to copy the new songs from each computer, thus synchronizing both copies of the music library.
You could say that Syncthing is like unison except it can sync between more than 2 computers at once. And unlike rsync and unison, it can run continuously, syncing changes as they happen. Some people use it to replace Dropbox or Bittorrent Sync, but it has a lot of uses.
1 Like
Syncthing extremely slower than unison
I am a long-term unison user. A friend asked me to evaluate syncthing. I have significant experience evaluating commercial two-way sync software, and unsuccessfully corresponding with their developers over undesired program behavior.
unison is written by Benjamin Pierce (a world-class computer scientist) with well-informed community support. There are two issues that unison gets right, and all commercial products get wrong: symlinks, and atomic directories.
symlinks should just be copied as-is, with all responsibility for their usefulness assumed by the user. One doesn’t want a sync program to ignore the file or go off for ten minutes if it finds a symlink, same as if it finds porn on your computer. Just copy it. Yet every commercial product mishandles symlinks. I saw rather sanctimonious responses when I reported “bugs” in each case to commercial products. They each have a private group-think justifying that they’re right (even though they each do something different, sometimes just what bad code accidentally does) because they get a cacophony of conflicting, uneducated user requests and they don’t really understand the problem. Sure, many users don’t deliberately use symlinks, but local, relative symlinks appear for example inside MacOS application bundles. Last I checked, every commercial product broke such links by applying whatever their ill-considered policy was for deliberate symlinks.
I believe that syncthing gets this right, but it is poorly documented. It also experiences a cacophony of conflicting, uneducated user requests, and old Windows behavior compounds matters further. So one can’t tell without spending hours studying the support requests, or making an actual experiment (I didn’t).
Atomic directories are a relatively new feature in unison: One can declare a directory atomic, forcing the user to choose at the directory level when there’s a conflict.
I declare .git directories atomic. A better example: A MacOS .sparsebundle disk image file appears as many files (bands) inside a directory, but is intended to be seen by the user as an atomic file, not a directory. This has the advantage of more efficient backups: If one makes a minor change to a large mounted disk image (say, a few MB to a multiple GB disk image) then backup software isn’t forced to make a new copy of the entire multiple GB disk image.
If one makes minor changes to the same mounted disk image on two machines, and then does a two-way sync, one could buy the farm. Most likely, there will be a conflicting root file alerting one to the problem. Far cleaner to simply be forced to choose one disk image directory over the other. Functionally, the entire disk images are in conflict, not specific files within.
The ability to declare atomic directories is not a feature of any other two-way sync software, and it should be. I see no evidence that this is supported in syncthing, though behavior in this direction could be undocumented. A good heuristic: If a naive user can’t easily open a folder to reveal its contents (say, a Mac application bundle, or a sparse disk image) then the supporting directory should be treated as atomic by default.
1 Like
How is this unclear with regards to whether and how symlinks are synced? https://docs.syncthing.net/users/faq.html#what-things-are-synced
There’s indeed no such thing as atomic directories in Syncthing. I totally see the value of it in general, but it would be a lot of work for a narrow use case.
1 Like
I searched the documentation for ‘alias’ and ‘symlink’ but not ‘symbolic’. My bad. I did not read the documentation cover-to-cover. I did spend half an hour Googling and reading forum posts / feature requests / bug reports where ‘symlink’ seemed to be the term of art. Perhaps add ‘symlink’ to that section of documentation?
I believe that I understand what is meant by “synced” here, but given the major players that bungle this, perhaps it would be helpful to spell out that symlink files are copied as-is like any other file, and that their suitability in the destination is the user’s responsibility. DropBox is the dumb gorilla in the room, and it’s also so convinced that what it does instead is right that it too is pithy in documenting it. If everyone got this right, you’d be fine being succinct. There is however a question leading reasonable people to be very suspicious of how any sync software handles this.
1 Like
Symlinks are indeed a mess. It wouldn’t hurt to add an “as is” somewhere in that doc sentence. It says symlinks are never followed but it doesn’t explicitly deny trying to do fancy stuff to adjust symlinks to their new environment or something.
Otherwise I stand by my opinion that if unison works and better fulfills the requirements, you should use unison. (General “You”). Atomic directories sound neat but doesn’t fit super well into how syncthing syncs so I’m skeptical you’ll see an implementation in the foreseeable future.