On Wed, Aug 06, 2014 at 11:51:00AM -0400, Al Faller wrote:
> Hi,
> I am working with csync2 on centos, utilizing lsync as documented in this
> blog post:
> https://www.krystalmods.com/index.php?title=csync2-web-server-file-sync&more=1&c=1&tb=1&pb=1
> Unfortunately, I have noticed that csync2 seems to be rounding the
> modification time of the file when it is transferred.  So, it is
> unfortunately transferred twice.  For example in a simple 2 node cluster -
> If on node1, I create a file call temp.txt with a modification time of:
> 2014-08-06 11:36:26.719294131 -0400
> csync2 dutifully copies the file over to node2, but when it writes the
> file, it makes the modification time:
> 2014-08-06 11:36:26.000000000 -0400
> So, now node2's lsync sees this as a change and notifies csync2 again
> (which I would expect) - but csync sees that the file's modification times
> do not match, and copies the file back over to node1 and sets the
> modification time to:
> 2014-08-06 11:36:26.000000000 -0400
> Any thoughts on how to prevent the double copy from happening?

prepare a patch to csync2 checking for availability of
stat.st_mtim.tv_nsec, encode that (in a backward compatible manner)
in the csync2 "wire" protocol, and change the use of utime() to utimes(),
providing full struct timeval (not just the time_t as it is now).

And then hope that the timestamp granularity on all used file systems
is sufficiently similar.

Alternatively use FAT, it has a granularity of 2 seconds ;-)



Csync2 mailing list

Reply via email to