Reading for area during rsync

[Jamie Lokier]

Matt McCutchen wrote:
> > 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.

Also:

(4) Support microsecond or nanosecond mtimes, on systems that support it.

(5) Support detecting file changes (e.g. using
kqueue/dnotify/inotify/etc.) independent of mtime, on systems that
support it, for the duration of reading each file.

-- Jamie