Hello!
SyncEvolution's ActiveSync backend uses the sync anchor passed into
StartDataRead() for change tracking. The new anchor is created in
EndDataWrite(). The sync anchor is the ActiveSync "sync key", created
and updated by the ActiveSync server as changes are made to the data.
I now have the following situation: because of a misconfiguration of the
client, it attempts to start a sync with an invalid sync key. The
ActiveSync server rejects it in StartDataRead(), which returns a 10500
error code.
This is the stack backtrace at that point (Synthesis engine running as
SyncML client):
#0 sysync::TPluginApiDS::apiReadSyncSet (this=0x1271be0, aNeedAll=false)
at
/home/pohly/syncevolution/libsynthesis/src/DB_interfaces/api_db/pluginapids.cpp:1166
#1 0x0000000000937285 in sysync::TCustomImplDS::makeSyncSetLoaded
(this=0x1271be0, aNeedAll=false)
at /home/pohly/syncevolution/libsynthesis/src/sysync/customimplds.cpp:3246
#2 0x0000000000932105 in sysync::TCustomImplDS::implStartDataRead
(this=0x1271be0)
at /home/pohly/syncevolution/libsynthesis/src/sysync/customimplds.cpp:1667
#3 0x000000000099fde0 in sysync::TStdLogicDS::startDataAccessForClient
(this=0x1271be0)
at /home/pohly/syncevolution/libsynthesis/src/sysync/stdlogicds.cpp:921
#4 0x00000000009a14c5 in
sysync::TStdLogicDS::dsBeforeStateChange(sysync::<anonymous enum>,
sysync::<anonymous enum>) (this=0x1271be0,
aOldState=sysync::dssta_syncmodestable,
aNewState=sysync::dssta_dataaccessstarted)
at /home/pohly/syncevolution/libsynthesis/src/sysync/stdlogicds.cpp:1428
#5 0x000000000091f940 in
sysync::TBinfileImplDS::dsBeforeStateChange(sysync::<anonymous enum>,
sysync::<anonymous enum>) (this=0x1271be0,
aOldState=sysync::dssta_syncmodestable,
aNewState=sysync::dssta_dataaccessstarted)
at /home/pohly/syncevolution/libsynthesis/src/sysync/binfileimplds.cpp:394
#6 0x0000000000930092 in
sysync::TCustomImplDS::dsBeforeStateChange(sysync::<anonymous enum>,
sysync::<anonymous enum>) (this=0x1271be0,
aOldState=sysync::dssta_syncmodestable,
aNewState=sysync::dssta_dataaccessstarted)
at /home/pohly/syncevolution/libsynthesis/src/sysync/customimplds.cpp:1101
#7 0x000000000090f7ba in
sysync::TODBCApiDS::dsBeforeStateChange(sysync::<anonymous enum>,
sysync::<anonymous enum>) (this=0x1271be0,
aOldState=sysync::dssta_syncmodestable,
aNewState=sysync::dssta_dataaccessstarted)
at
/home/pohly/syncevolution/libsynthesis/src/DB_interfaces/odbc_db/odbcapids.cpp:1698
#8 0x000000000095965c in
sysync::TLocalEngineDS::changeState(sysync::<anonymous enum>, bool)
(this=0x1271be0,
aNewState=sysync::dssta_dataaccessstarted, aForceOnError=false)
at /home/pohly/syncevolution/libsynthesis/src/sysync/localengineds.cpp:4178
#9 0x0000000000957e6f in sysync::TLocalEngineDS::engInitDSForClientSync
(this=0x1271be0)
at /home/pohly/syncevolution/libsynthesis/src/sysync/localengineds.cpp:3582
#10 0x0000000000957e21 in sysync::TLocalEngineDS::engInitForClientSync
(this=0x1271be0)
at /home/pohly/syncevolution/libsynthesis/src/sysync/localengineds.cpp:3568
The error causes apiReadSyncSet() to bail out, without ever calling
EndDataWrite() in that session. Because the backend never gets the
chance to reset the sync anchor, the next sessions just do the same
thing again and again.
How can the backend tell the engine to throw away the sync anchor and
thus force a slow sync? Should it return a special error code?
The backend could manage its own cross-session state, but that reduces
the usefulness of having the sync anchor(s) managed by the engine quite
a bit.
--
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.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
