[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