2002-10-10-16:09:16 Derek Simkowiak: > I'd like to know what you mean by "rsync handles it fairly well". > Any information you have would be greatly appreciated.
I think I can help a little here. Each rsync at the destination has its own separate remote rsync process whacking on the file. Rsync doesn't whack directly in the target file; rather, the remote rsync process uses some combination of wads of data read from the target file plus wads of data passed from the sending rsync, to assemble a new copy; it's assembled in a tmp file and moved into place. The rsync opens the target file to read; if some other rsync moves a new file into place before that, there's no concurrency, this is pure sequential rsyncs; if it moves the target file into place after it's been opened, the older copy of the target will still be used by the process we're looking at, through the open file handle it holds; the intruding copy won't have any effect. The tmp files used to build the new copies have some magic juju dust sprinkled on the filename; while I've not analyzed them or looked at the code to figure out where the magic comes from, certainly collisions here are improbable if not formally impossible. All in all, it's pretty safe to have multiple rsyncs aimed at the same destination file; you'll get one of 'em, intact. And I think it's even possible that if every invoker uses --backup with a different --backup-dir, it's even possible that rsync might guarantee the safe archival of _every_ copy that's sent. I wouldn't bet against it, rsync seems to be some pretty serious engineering. -Bennett
msg05201/pgp00000.pgp
Description: PGP signature
