tv_nsec field in stat structure is not used (source code I checked does not refer to it) if available. This results in files being not "completely" aligned because the original file will have nanoseconds set all other destinations have this portion of file information set to 0. A pratical example of when this might become a problem is Apache's ETag generation, Apache HTTPD correctly reads tv_nsec when available (Solaris,Cygwin have that feature for example) and puts the value of tv_nsec in the ETag. A cluster of Etag-generating httpds behind a load balancer would generate all the same ETag but the "master" source which would have an ETag with no microseconds (ETags are limited to microseconds..) so defeating the ETag purpose.
The latest git repository has support for nanosecond timestamp values. The values are transferred as part of the file-list (when both sides are speaking the most recent (dev-version) protocol 31), and the receiver will attempt to set it. Probably only works on Linux at the moment. Things to enhance: * Figure out if there are other nanosecond setting functions that should be supported besides utimensat(). * Figure out a good heuristic for allowing the nanoseconds to be compared (when determining if a file is up-to-date) without getting tripped up by those filesystems that round/truncate time values. The current code leaves the quick-check algorithm unchanged, as it only checks the file's size, and the seconds portion of the modtime.
Maybe the easiest fix here would be, to extend cmp_time() in util.c to receive two more parameters: file1_st_mtimensec and file2_st_mtimensec? I guess this is not going to be portable...