syncrclone VS lfsrclone

Context: I am the developer of a "competitor" to bisync called syncrclone. I lay out a good-faith comparison here

I am the author of syncrclone which can do any remotes. It has its own pros and cons. See my comparison

I am the author of another option: syncrclone. I am, of course, biased but I think it actually works better than bisync, has a more robust algorithm, and is more compatible (including with WebDAV remotes). I wrote a good-faith comparison here. It is also more advanced to use including knowing that if you use webdav, you must set compare = 'size' (but hey, now you know!).

Another idea. I am the author of syncrclone, a python wrapper around rclone that does bi-directional sync. It predates bisync but not the other python wrapper on which bisync is based.

Way different experience but I wrote a bidirectional sync tool that wraps rclone and can do it to Dropbox. I use it on Dropbox and OneDrive on my super old macs. My newer ones I just use the native OneDrive client. https://github.com/Jwink3101/syncrclone

More advanced but I wrote my one bi-directional sync tool. I use my tool to keep some thing synced across multiple machines and mount for things I don’t also need locally. It’s not as svelte as how OneDrive keeps things local and remote but it works.

This borrows a lot of ideas (and some code) from my other major rclone tool, syncrclone.

Apparently I love writing wrappers around rclone (syncrclone, lfsrclone, PyFiSync, amongst others).

At home, I use my own tool I built to sync but that is not user friendly really.

This is quite the hack when there is bisync built in or third-party tools that interface directs and will work better. One example, which I built so I am biased, is syncrclone

Apparently I love writing wrappers around rclone (syncrclone, lfsrclone, PyFiSync, amongst others).