Today Synchi is finally public! It's designed for syncing files between two locations (local or over SSH). It detects conflicts, and lets you decide what to do.

Why not rsync/Unison/Syncthing?

rsync has no memory between runs and is one-way
Unison needs to be installed on both sides
Syncthing requires always-on daemons

Synchi runs on demand, works over SSH, and only transfers what actually changed.

GitHub: https://github.com/jakobkreft/synchi
Docs: https://jakobkreft.github.io/synchi/

I use it daily for syncing a shared folder between my machines and an android phone. Works great in combination with Tailscale/WireGuard so that you can sync files remotely.

top 6 comments

sorted by: hot top controversial new old

[–] ranzispa@mander.xyz 1 points 3 hours ago

Very nice! I'll keep using unison for now as I need something stable and reliable, but I'll keep an eye on the project and may switch to it eventually.

[–] bad1080@piefed.social 10 points 2 days ago (1 children)

It detects conflicts, and lets you decide what to do.

does it continue to sync the rest on conflict or does it halt for user input?

[–] jak0b@lemmy.ml 11 points 2 days ago (1 children)

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.

[–] bad1080@piefed.social 10 points 2 days ago (1 children)

but conflicts still halt for user input

i never understood this behavior. starting a large data transfer only to come back an hour later to find it halted at 5% due to some conflict. why not put those files at the end of the queue and resume with the rest?

[–] jak0b@lemmy.ml 24 points 2 days ago (1 children)

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.

[–] davidgro@lemmy.world 8 points 2 days ago

This makes so much more sense than the Windows behavior.