[sync] Client and server timestamps don't match
Karsten Fourmont
fourmont at gmx.de
Tue Mar 13 09:12:44 UTC 2007
Hi,
If it's writing to the datatree then it's still an outdated syncml module.
Please check your pear path for an old SyncML module.
Use pear list -c pear.horde.org to see what's installed.
Unfortunately I don't have access to my test machine atm so I can't
verify this on my own. On my development machine I use the symlinks
created by framework/devtools/fw-createsymlinks
(Horde pear modules must not be installed in this case. pear list -c
pear.horde.org should be empty).
Cheers,
Karsten
jochem at mondrian-it.nl wrote:
> Hi Karsten,
>
> After doing a full clean install of horde and kronolith, I still find the
> same symptoms. I dropped the database I was using, removed the /horde
> directory off my webserver, checked out horde, framework, and kronolith with
> -r HEAD, ran install-packages.php, ran horde/scripts/sql/create.mysql.sql
> and kronolith/scripts/sql/kronolith_events.mysql.sql. I checked whether the
> horde_syncml table existed (it did). I cleared out all items on my pda and
> all items on the server.
>
> After doing all this, I tried syncing again. The initial sync is reported as
> such, and works perfectly. The second sync reports that the server and
> client timestamps _match_ and works well also (tested with a serverside
> delete that propagated to client side). The _third_ sync remarks that the
> client and server timestamps are mismatched, and that a slow sync is forced.
> The puzzling thing is that the second sync works, but that the server
> reports the anchor ts for the _first_ sync as being the last successful
> during the third sync.
>
> It seems that the first anchor ts is stored correctly. The second sync then
> compares this ts to the one stored on the client. They match, because the
> client and the server both synched correctly last time. The sync processes
> correctly, the logs on both server and client reflect this. The client
> stores a new anchor TS. The server, however, somehow does not.
>
> On the third sync, the server now reports it's last successful sync was
> sync1, with it's anchor TS. The client reports the ts it received for sync
> 2. This mismatch leads to a slow sync.
>
> When I read the post below, it seems like the anchor ts should now be stored
> in horde_syncml_map. When I look through mysql's tables, I only find the
> anchor ts in horde_datatree though, where it was before this update too.
> Could it be that the class SyncML_Device_sync4j hasn't been updated yet to
> use the new storage location (just guessing)? After a number of
> 'successfully' completed syncs, horde_syncml_map stays empty...
>
> I've checked the timestamps on the files in /usr/share/php/SyncML, and it
> seems that all files in there were at least overwritten today when I ran
> install-packages.php.
>
> Regards,
>
> Jochem
>
>
> -----Oorspronkelijk bericht-----
> Van: Karsten Fourmont [mailto:fourmont at gmx.de]
> Verzonden: vrijdag 9 maart 2007 18:35
> CC: sync at lists.horde.org
> Onderwerp: Re: [sync] Client and server timestamps don't match
>
> Hi Jochem,
>
> the cvs change of Feb 11th requires a database update. See mail below:
>
> And of course as usual you need to do a install-packages.php after an
> update.
>
> Cheers,
> Karsten
>
> ---
> Hi,
>
> there's a new SyncML version in cvs.
> The syncml map is now finally moved out of the datatree and into a
> separate sql table horde_syncml_map.
>
> 1) upgrade everything to cvs. You need current cvs versions of kronolith
> and turba as well. The datatree issue is also fixed in cvs.
>
> 2) create the sql table by running horde/scripts/sql/horde_syncml.sql
>
> 3) Do a sync. As all old mapping info is lost, the first sync will be an
> initial slow sync again. So if you use the synthesis client, you should
> do a "reload device" which deletes all data on the devide and then loads
> everything from horde. If you use a client that doesn't have this
> feature: I made fixes in kronolith and turba so that there should be no
> duplicates when doing an initial slow sync with data on the device and
> in horde as well. However for notes and tasks such a slow sync results
> in duplicates at the moment.
>
> Sorry for the inconvenience, but this was really necessary. Performance
> should be greatly improved with the new table.
>
> Cheers,
> Karsten
More information about the sync
mailing list