Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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 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 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.
Last edited by bennypr0fane; 12-19-2013 at 04:00 PM.
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.
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?
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:
Code:
Unison shares a number of features with tools such as configuration management packages (CVS,
PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional
mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc)...
Unlike simple mirroring or backup utilities, Unison can deal with updates to both replicas of
a distributed directory structure. Updates that do not conflict are propagated automatically.
Conflicting updates are detected and displayed.
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.
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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.