> But this won't work if the change that occurred on the sending side > after the transfer started happens within the same second, and the > mtimes have only one second resolution, will it? > > That's quite likely, if the file is reasonably small and the first > rsync managed to send a mixture of old and new content - that implies > the other program changing the file was running at nearly the same time.
I would stop short of saying this situation is "quite likely", but it is definitely a concern. I can think of three possible ways to avoid it: (1) Use --checksum, but that's really slow. (2) Have rsync set the source file's modtime to the epoch and check the modtime when it finishes reading, at which point it sets the modtime back how it was unless another process has interfered (race here). (3) Have rsync take out a fcntl(2) mandatory lock and/or lease on systems that support it. -- Matt McCutchen [EMAIL PROTECTED] http://mysite.verizon.net/hashproduct/ -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
