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.