I've been sherlocked. As of v1.58.0, rclone now has bisync. syncrclone works fundamentally differently as compared in syncrclone vs bisync (and rclonesync-v2). For the time being, I fully plan to continue development. To be 100% clear, I have no hard feelings about it.
But I wrote the below documentation for syncrclone if anyone is interested.
Again, this is a good-faith comparison. Please correct any errors and I will update the documentation
syncrclone vs bisync (and rclonesync-v2)
Preface
Let's be 100% clear and upfront. I AM BIASED. I wrote syncrclone to fill a need not met by bisync / rclonesync-v2.
Additionally, both are great tools and I am not disparaching the hard work of the various developers! The thing to remember is that bi-directional syncronization is fundamentally harder than mirroring because you need to keep the state. And therefore, it is also more opinionated.
rclone bisync is based on rclonesync-v2. So I will just say bisync even though some of this is experiance from the other
One final note: These may be wrong. I based it on experiance, reading, discussions, and inference from said activities. I do this in good faith but may be wrong. Please correct me!
Algorithm Differences
Before I go into details on the differences in features, there is a fundamental difference in algorithms. It is best described as follows.
- bisync separately compares the current state to the past state to generate changes. It then propagates those changes and resolves conflicts.
- syncrclone first compares the current state of each machine and then uses past state to resolve conflicts and deduce needed changes.
Both theoretically result in the same final process. But the latter only implicitly needs the prior state while the former requires it to work. As such, syncrclone does not have any need to notify it that this is the first sync and only has a singular code path.
It also explains some (but not all) of the feature differences below
Comparisons
Again, these are in good-faith but may be wrong. Please correct them as needed
| Feature | syncrclone | bisync | Comments |
|---|---|---|---|
| Mode of configuration | Config file (path specified implicitly or explicitly) | Command line flags | Command line is cleaner and more consistent with rclone but there is a lot of configuration that needs to be kept (e.g. filters, etc) which makes the config file really useful. Makes the sync directories more like a repo (a la git) |
| Change Propagation | Compare *current* state and use previous to resolve conflicts | Propagate differences between current and previous to both sides, then compare | *Theoretically* both should be identical but syncrclone is more robust to issues with knowing the previous state. It also removed the need for `--first-sync` type flags and other safety mechanisms. If they have never been synced before, you get the union of the two sides which is safer. No deletes. It also better matches how rclone currently does the comparison |
| First sync mode | Implicit. Same code path | Explicit. Must handle differently | |
| Filters and affects | Can *safely* change filters except for `--include-if-present` | Must rerun with first-sync mode. Loses some conflict detection | This difference is due to the algorithm and when filters get applied |
| Comparisons | ModTime, size, and/or hash | ModTime | Reliance on ModTime *severely* limits which remotes can be used bisync. ModTimes can also be fragile when restoring from backups. |
| Previous state data | Default: Stored inside each remote and named based on a unique name for the pair. Alternative: Can be stored on any *other* rclone remote | Global storage on the machine itself in a cache-like dir | Saved state on the machine means that if you sync two remotes (e.g. OneDrive to Google Drive), you *need* to use the same machine. Also can lead to issues with paths and duplicates. However, saved state on the remotes leaves artifacts. Syncrclone can be configured to use a different remote but it is more complex and not default |
| Rename/Move Tracking | Optional. Settable with ModTime + size, hash, or size alone (though latter not advisable) | None that I am aware of | |
| Reduce re-hashing of files | Optional. Can keep previous hashes. Or with new hasher remote. | Hasher remote | Hasher remote didn't exist when syncrclone was first made. Both should work fine, like saving the previous state, the hasher is in a cache-like dir |
| File backups | Optional. Either in the remote or a different one | None | |
| Conflict tagging | Yes. Optional | ??? | i.e. keep both but rename one with a suffix |
| Delete Fail Safe | None (except backups) | Yes. Can set a max-deletes | has other protections including the default design which will not delete from mis-specified remotes |
| Second file listing | Yes but experimental feature to not-need | Yes | Syncrclone's experimental feature may soon be default. Saves a lot of time on slow-to-list remotes |
| User Support | Minimal | Forums, Professional developers. Larger community | I am a hobby developer and syncrclone is a side hobby project |
| Platforms | Tested on macOS and Linux. No idea if this works on windows | Presumably all platforms | I never tested syncrclone on Windows. If it doesn't work, it very likely can be fixed to work. |
| Install | Must install python3. More complex | None. Built in |