• 2 Posts
  • 12 Comments
Joined 5 months ago
cake
Cake day: October 22nd, 2025

help-circle
  • Thanks for correcting me! Honestly, I haven’t used rclone bisync myself so thanks for sharing it. I have to give it a try now. rclone definitely looks a lot more compex feature-rich tool. Synchi I think would be alot simpler to setup and works great for my specific use case of syncing notes and files between my devices. Perhaps, targeted users is the distinction? Anyways I need to try it and see what good things I can learn from it.


  • rclone bisync can do two-way sync, yes, great tool, especially for cloud backends and more automated syncs. Synchi is a lot simpler and more focused: works over SSH, nothing needed on the remote side. The key difference is that Synchi shows you exactly what it’s about to do (copy A→B, copy B→A, delete in A, delete in B) and asks before changing anything. Conflicts get an interactive UI. No surprises.



  • This is exactly how I use Synchi! Same idea but I use Logseq instead of Obsidian (very similar open-source alternative, worth checking out). Works great for syncing markdown notes between computers and my phone on demand. Of course I need to remember to sync before switching devices, but I prefer this then constant running in the background.

    Haven’t thought about an Obsidian/Logseq plugin but honestly that sounds like a great idea… For now it’s CLI only, but I can definitely see the value.



  • Great question! Let me sum it up here for others:

    rsync is one-way only and has no memory between runs, every execution starts from scratch. Synchi is two-way, stateful (knows what changed since last sync), and content-aware (uses hashes, so no false positives from timestamp changes). It also handles conflicts explicitly instead of silently overwriting.

    That said, rsync is still the better tool for backups and one-way mirroring. Synchi is for when you need true bidirectional sync.

    Here is also a comparison with unison and syncthing: https://jakobkreft.github.io/synchi/why.html





  • It doesn’t work that way. Conflicts are resolved before any transfer starts. The flow is:

    Scan both sides and compare (compute file hashes or just compare mtime, no data transferred)

    Show conflicts if any → you resolve them

    Show copy/delete summary → you approve

    Only then does the actual transfer begin. So you never come back to find it halted mid-transfer. All decisions happen upfront while it’s just reading metadata, which is fast even for large trees.


  • It compares everything first (scan, diff, hash), then halts before any changes are made. You see a full summary of what will happen, and approve each category separately (copies, deletes). It’s designed to be very transparent. Every change must be approved before anything is written.

    Conflicts get their own interactive screen where you pick per-file: keep A, keep B, or skip. Nothing is written until you’ve resolved all of them.

    If you want to skip the prompts, --yes flag auto-approves, but conflicts still halt for user input. Flags --force root_a or --force root_b are used for mirrors one way here conflicts are not possible.