Re: [SyncEvolution] Failed with status code=20048, statistics are incomplete!! - Memotoo
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
the
> > > other a number. Both are strings sent by the Memotoo server. Did you
> > > perhaps change the anchor formatting from "seconds since epoch as
time
> > > stamp" to "seconds since epoch as integer"? I haven't
checked whether
> > > 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
sync)
[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.