On Fri, 2010-07-02 at 16:52 +0100, Gladstone wrote:
On 28/06/10 21:42, Patrick Ohly wrote:
> Can you reduce it to a simpler combination of syncs, say, add special
> character in FB, send to server, then to phone?
>
> Check at each step that the data was transfered okay. The data stored by
> the file backend uses UTF-8.
I'm having difficulty reproducing this exactly. However, I have noticed
that deleting an event from TB is not synced to the server and in-fact
is re-created.
Here is the workflow:
1. Create event on phone
2. Sync to server
3. Sync TB -- event appears correctly
There's a SyncML communication problem in this sync:
[2010-07-02 16:14:06.731] Created command 'Status' (outgoing)
[2010-07-02 16:14:06.731] Deleted command 'Status' (outgoing MsgID=0, CmdID=0)
[2010-07-02 16:14:06.732] No DevInf received or cached, request DevInf using GET command
[2010-07-02 16:14:06.732] Created command 'Get' (outgoing)
[2010-07-02 16:14:06.732] 'issue' - issuing command, Cmd=Get [--][++] [->end]
[->enclosing]
[2010-07-02 16:14:06.732] Get: issued as (outgoing MsgID=1, CmdID=9), now queueing for
status
[2010-07-02 16:14:06.732] Outgoing Message size is now 26724 bytes
[2010-07-02 16:14:06.732] End of 'issue' [->top] [->enclosing]
...
[2010-07-02 16:14:07.001] 'processStatus' - Processing incoming Status [--][++]
[->end] [->enclosing]
[2010-07-02 16:14:07.001] Started processing Command 'Status' (incoming MsgID=2,
CmdID=1)
[2010-07-02 16:14:07.001] RECEIVED STATUS 200 for for command 'Get' (outgoing
MsgID=0, CmdID=9)
[2010-07-02 16:14:07.001] No command found for status -> ignoring
[2010-07-02 16:14:07.001] Deleted command 'Status' (incoming MsgID=2, CmdID=1)
[2010-07-02 16:14:07.001] End of 'processStatus' [->top] [->enclosing]
[2010-07-02 16:14:07.001] Created command 'Status' (incoming)
[2010-07-02 16:14:07.001] 'processStatus' - Processing incoming Status [--][++]
[->end] [->enclosing]
[2010-07-02 16:14:07.001] Started processing Command 'Status' (incoming MsgID=2,
CmdID=1)
[2010-07-02 16:14:07.001] RECEIVED STATUS 200 for for command 'Put' (outgoing
MsgID=0, CmdID=5)
[2010-07-02 16:14:07.001] No command found for status -> ignoring
[2010-07-02 16:14:07.001] Deleted command 'Status' (incoming MsgID=2, CmdID=1)
[2010-07-02 16:14:07.001] End of 'processStatus' [->top] [->enclosing]
Note that the client seems to use an incorrect MsgID=0 in its reply. It should use
MsgID=1.
[2010-07-02 16:14:10.323] - Not yet received status for command 'Put', (outgoing
MsgID=1, CmdID=5)
[2010-07-02 16:14:10.323] - Not yet received REQUIRED status for command 'Get',
(outgoing MsgID=1, CmdID=9)
[2010-07-02 16:14:10.323] - Not yet received status for command 'SyncHdr',
(outgoing MsgID=5, CmdID=0)
[2010-07-02 16:14:10.323] SESSION CANNOT END - Not yet received REQUIRED status for some
of 3 commands
...
[2010-07-02 16:14:10.331] 'DSAbort' - Aborting datastore sync,
abortStatusCode=400, localProblem=yes, resumable=yes
I do not see any other reason for DSAbort with status code 400 in the
log file. Lukas, is the reaction of the engine for missing statuses this
abortStatusCode=400 error?
This happens with the Funambol Thunderbird client. The client itself
seems to believe that the sync finished successfully.
Gladstone, which version of the client are you using? Are you using the
up-to-date one?
4. Delete event from TB
5. Sync TB -- event is recreated
This session then runs in "slow sync" mode because of an anchor
mismatch, which is probably the result of client and server disagreeing
about the success of the previous sync. Deleting items does not work in
slow sync mode.
[loss of properties not supported by some peer]
> Unfortunately there isn't much that can be done about this.
Picking the
> subset of the data which is supported by all devices typically works
> best.
Could you outline how I would go about that?
First look at what each peer supports in its GUI. Typically that is what
it should be able to synchronize. Then run experiments sending data back
and forth. Then for example, if you find that spouse name in Evolution
is getting lost, consider using a note with the spouse name inside
instead.
--
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.