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 [EMAIL PROTECTED] 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? -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
