Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

How does rsync handle the possibility of interference with another rsync on the same machine? I have read all the documentation I can find but do not see any mention of this. I am going to run some experiments but am concerned that they may not reveal the full extent of any problems I might run into.

Here is the scenario. I want to keep two machines in sync. Each machine monitors for file changes in a directory, and when it detect some, it runs rsync to sync that directory to the remote machine. Normally, only one machine at a time will have a file changes occurring, but what would happen if the same file changed on both machines at the same time, presumably to something different? Will rsync detect that it is running on both machines and correctly handle the situation (e.g. sync only the newer file over) or could it go horribly wrong resulting in corruption or indeterminate behavior?

Will the outcome be different if there is an rsync server on each machine versus using ssh? I haven't seen any good explanation of the benefits to using one method versus the other.

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

In short - two rsync processes will not know anything about each other.

At run-time, rsync will simply carry out the action which is appropriate given the current state of the source and destination files and the arguments/flags passed (i.e. if you are specifying --dry-run, --delete or any other behaviour-altering flags).

This is what makes rsync (and also other uni-directional synchronisation tools) very dangerous in certain environments, and also why solutions like Windows Server's DFS and Linux's clustered filesystems like GlusterFS and GFS or block-level replication tools such as DRBD more applicable if you're looking for true bi-directional synchronisation.

You may find this flag useful (from the rsync man page), but you may run into unexpected/unpredictable behaviour, especially if you combine with --delete:

-u, --update                skip files that are newer on the receiver
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.