Simultaneous rsyncs?

[Tim Conway]

The last version to finish and be renamed over the existing target file 
would be the one you end up with.  No mixing, and no error returned, 
either to the winner or the loser, just a perfect copy of the last version 
sent, just as if you had two people editing the same file in a single 
directory... the last one to save wins.
If you're going to have multiple modifiers per file, you must resolve 
control.  You're right, you do "need some sort of 
queuing or interlock mechanism", not just to prevent simultaneous rsyncs, 
but simultaneous edits.  That's why we have things like CVS, RCS, SCCS, 
PVCS, BitKeeper, etc.. 
By the way - rsync gets along VERY well with CVS.

If this directory is already under version control(even just good 
coordination among personnel), and it's going out for read-only use, 
you're sailing smooth.
When one rsync finishes and moves its temporary file over, it unlinks the 
old file and puts the new one in its place, so even if a subsequent rsync 
is still using the destination file for a template, it won't matter, 
because it'll still have the inode open, and will work from the now 
nameless original file, and release it when it finishes, then delete the 
"new" original, and put its version in place.

On the other hand, I can't say what the consequences would be of modifying 
the source file in-place during a send.  I expect rsync notes changed 
mtime and restarts.  Wayne?

Tim Conway
Unix System Administration
Contractor - IBM Global Services
desk:3032734776
conway at us.ibm.com


What would happen if two people ran rsync on the same set of source 
files to the same destination machine?  Do we need some sort of 
queuing or interlock mechanism to prevent simultaneous rsyncs?

More problematical is when two or more distributions overlap.  What 
would happen in that case?