I wonder why Rsync seems to be THE go-to standard for virtually all syncing everywhere in the *nix-world, whenever there is some kind of file syncing involved, it's always Rsync, even though it syncs one-way only.
Maybe it can be scheduled to sync first one way, then the other, in 2 separate procedures, or however that works. Anyway, I believe it is used a lot for syncing in both directions and I don't understand why a two-way-sync protocol like e.g. Unison is not more commonly used in the first place.
Or maybe my perception is just plain wrong, and Unison et al. is just as common.

I am trying to figure this out because I have a cloud storage provider that offers mounting the cloud storage as a network drive in any system via smb share, nfs, ftp or webdav.
That means though there are no local copies of the files stored automatically like e.g. in Dropbox, and any access to cloud files is actually an internet download.
That's why I want to have a local directory synced with the cloud drive - two-way, like with Dropbox.
The provider allows for syncing access, you guessed it, via Rsync.
If figure it'd be possible to just use Unison instead, but because of my initially described impression that Rsync is sorta what you're supposed to use, I'd like to know if anyone thinks Rsync would be somehow advantageous.
If it turns out so, then I need to figure how to achieve 2-way-syncing with a 1-way-tool, so how does that work?

I do not really understand how that two way syncing should work. I think you need to specify one source and all the others can be synced (by rsync), but what to do if a file was modified here and there? What to do if a file was removed here and modified there? ..... How to handle renaming, moving files/dirs ....

I can rsync in two directions.

Well would you care for a short (or longer) explanation how you do that?

I guess with 2-way-syncing it's probably more common to run into conflicts that need to be resolved by the user, but generally I figure you just need well-made guidelines for which changes get priority over others.
If all ends are connected to the cloud whenever you change something, it should be easy to go chronologically.
If you make a change that is not synced immediately, and then make a different change to another location/instance before syncing the first change, then syncing that first one will lead to two conflicting statuses. I've seen that very rarely though with Dropbox, everything goes the way I want it to go most of the time, so they must have a pretty smart solution for this.

However I am looking for confirmation or rejection of my hypothesis that Rsync
1. Can sync both ways and
2. is preferable over a true two-way solution for technical reasons like e.g. greater speed, reliability, flexibility etc.

or
http://www.thegeekstuff.com/2010/09/...mand-examples/
examples #4, and $5

Now thats a habit, its a classic.

OT: Depends on your use case. If oyu just want some kind of backup rsync is your friend. If you want to modify files regardless of the location. Say online and offline you would use unison. Never played with unison but with rsync you just mirror stuff. If you dont edit the same file you can 2 way sync with rsync but as soon as the same file gets changed on both location rsync screws.
Maybe think of rsync as a featured cp command. And unison more as of a revision control. That just make clear where to use which one.

2 members found this post helpful.

If I understand these samples correctly, neither will resolve a situation where changes have been made to both ends. In such a case, if for instance there were changes made to the same file, only one of the two will make through, no?

That is correct.

So what you mean by two-way sync is not a sync at all, but a merge.

Can unison do that - automatically and safely?

*** UPDATE ***

Being unfamiliar with Unison, and having a short break, I looked into it, here.

From that page:

So, although they call it "syncing", it it more akin to a revision control system and does in fact allow you to merge changes from both ends, but still requires human intervention to resolve conflicting updates, as would be expected.

For that use I think Git is probably a more useful comparison than rsync. And asking why Git is used more widely instead of Unison would be a more appropriate question. Rsync does not perform such merges.

1 members found this post helpful.

What is?

Just a line from a song I had in mind.

you'll need 2 unison profiles, as an example:

vi .unison/sendup.prfand run it with:
vi .unison/bringdown.prfand run it with:
Reliable backups and I can't emphasize this enough, aren't "enough". They need to be tested.
I hope you have some.

Have fun!

It appears that Unison needs another instance of Unison to be installed on a remote server in order to sync with it, which sucks very bad. That server is only storage, I can't make it run any kind of program.
Remote sync can be done via SSH, RSH or TCP.
I wonder though, if the server is mounted under my local file system, e.g. with SMB, would Unison still consider that a remote system?

I'd say that it takes it as a local filesystem so should work.

I believe it would not.
It should behave as any locally mounted FS.