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