Reading for area during rsync
jamie at shareable.org
Tue Jan 31 09:15:55 GMT 2006
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.
(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.
More information about the rsync