The way script works, it runs change monitor on both sides; if there is a change on local side, it will do local->remote sync; if there is a change on remote side, it will do remote->local sync.
This can go wrong in many, many ways. Here is the first example that came to my mind: you started a process on remote machine which creates lots of small files -- maybe extracting an archive, or generating images. So the syncer keeps syncing those files in remote->local direction. Meanwhile, you got bored watching the script and decided to edit some code. POOF! Any edits you make are continuously reverted.
Oh, and there is no error checking anywhere. Did your network had a hickup? Tough, we will march on anyway. Let's it was not in lines 101 or 104 -- if these commands have transient failures, then your newly made changes would just get reverted.
If you care about your data, please do not use this. Use anything else -- syncthing, osync, unison were named in this thread, they are all good.
edit for clarity The trick is every sync step is with -u (not replacing updated files) and done again in the other direction before restarting the watch.
And the same deletion applies to network errors -- if ssh fails, then newly created files would get deleted.
That said, I agree that -u options does makes it less likely that files get overwritten. This option approach a some caveats, however -- archive extraction will mess the modification time, symlinks and directories are not handled properly. Still, regular IDE editing will work.
Still not sure how is it better than unison though :)
I personally run it in "-auto" mode -- every time I run the program, it shows me all actions it wants to do, any conflicts it detected, and asks me if I want to proceed.
If you want to run live mode, you can just run:
unison -ui text -repeat 5 . ssh://remote-host/dir
Works will for one-way or multi-ways syncing https://docs.syncthing.net/users/foldertypes.html
(Note that local locking can be helpful to prevent simulatenous modifications by editor and sync tool; but unfortunately Linux ecosystem is not designed with such locking in mind)
Amazing stuff. Brew, Cygwin and your favorite package managers have it.
almost any two rsyncs from the last 20 years speak to each other and do it rather quickly.
I agree with slowness -- I feel the recent versions are pretty fast on Linux, but it can be faster. Also it's "scan, then transfer" approach means it can take lots of memory if there is a lot of files.
Still, if you can your rsync in your application, use it. For automated backups, you cannot beat it. But unison has two unique advantages:
- Proper two way sync -- doing it safely with rsync is almost impossible.
- GUI/TUI which shows what changed and allows conflict resolution.
- GUI which shows
It's more so that I wish IDEs supported software like this. There's a plethora of such offerings such as CyberDuck, Expandrive, etc that would benefit from reduced read/seek activity if the IDE could just orchestrate when to emit changes to what it thinks is the "disk". As you noted on GitHub, such software gets really laggy when working in directories that aren't trivially small.
2. It doesn't actually replace Dropbox.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the service, is it reasonable to expect to make money off of this?
(Silly satire.)
It seems to be built for a different use case; Nextcloud (server/client) and Syncthing (P2P) are already excellent Dropbox alternatives.
For iOS coda is pretty good. I've used Codeanywhere for android; 2-way sync would need to be integrated in the app itself on these platforms, I would think...