On Tue, 2012-03-13 at 12:57 +0100, Thomas Pequet wrote:
Le 13/03/2012 10:43, Patrick Ohly a écrit :
> On Tue, 2012-03-06 at 17:16 +0100, Thomas Pequet wrote:
> > Le 06/03/2012 13:14, Patrick Ohly a écrit :
> > > Thomas Pequet wrote:
> > > It's a bit curious that in one case the anchor is a time stamp, in
> > > other a number. Both are strings sent by the Memotoo server. Did you
> > > perhaps change the anchor formatting from "seconds since epoch as
> > > stamp" to "seconds since epoch as integer"? I haven't
> > > 20120228T115051Z matches 1330608696000 when interpreted like that.
> > It is strange, Memotoo return only date with seconds (ex:
> > 1330608696000) not timestamp... So why SyncEvolution store the
> > timestamp ????
> SyncEvolution and libsynthesis treats the sync anchor as string. It
> should never convert to a time stamp. Does your user still have other
> logs? He can do a "grep -l -r 20120228T115051Z ~/.cache/syncevolution"
> to find all relevant log files.
I got logs for two sessions from Thomas. In the session from 2012-02-28
there is an entry for the anchor from Memotoo as UTC date/time:
[2012-02-28 12:50:51.753] Received <next> Remote Server
Anchor='20120228T115051Z' (to be compared with <last> in NEXT session)
Then in the next session, Memotoo reverts to the integer format:
[2012-03-01 14:31:36.449] Saved Last Remote Server Anchor='20120228T115051Z',
received <last> Remote Server Anchor='1330603400000' (must match for normal
[2012-03-01 14:31:36.449] Received <next> Remote Server
Anchor='1330608696000' (to be compared with <last> in NEXT session)
This confirms my theory that the Memotoo server switched between
different ways of formatting its internal time stamp.
There are no XML message dumps to proof it, but I am nevertheless
confident that this really what the Memotoo server sent. There simply
isn't any code in libsynthesis which transforms remote server anchors.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.