4:26 a.m.
http://bugzilla.moblin.org/show_bug.cgi?id=4703
Summary: ScheduleWorld: delete on server can not sync to client
(after doing slow sync)
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: major
Priority: Undecided
Component: SyncML
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: weibin.pan(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com
package: syncevolution-0.8.1.99.4.09beta3-1.1.moblin2.i586
steps:
1. delete all data first, configure a service with scheduleworld template:
$syncevolution -c -y username=<username> -y password=<password> -l
scheduleworld test
2. create one item on server, and run a sync to make all data synced:
$syncevolution --run -s two-way test
3. now server and client both have one item, run slow sync:
$syncevolution --run -s slow test
4. now server and client still both have one item, delete the item on server
and run two-way sync:
$syncevolution --run -s two-way test
after all these steps, now sever has no item and client remains one item, the
status of server and client is not synchronized.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:33 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
shuangeeer <yanshuang.zheng(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark(a)ScheduleWorld.com
--- Comment #1 from shuangeeer <yanshuang.zheng(a)intel.com> 2009-07-23 19:33:35 ---
Add Mark into CC list.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:39 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #2 from shuangeeer <yanshuang.zheng(a)intel.com> 2009-07-23 19:39:15 ---
What I have learned from these steps is that 'two-way' doesn't behavior
normally after slow-way synchronization.
(In reply to comment #0)
package: syncevolution-0.8.1.99.4.09beta3-1.1.moblin2.i586
steps:
1. delete all data first, configure a service with scheduleworld template:
$syncevolution -c -y username=<username> -y password=<password> -l
scheduleworld test
2. create one item on server, and run a sync to make all data synced:
$syncevolution --run -s two-way test
3. now server and client both have one item, run slow sync:
$syncevolution --run -s slow test
4. now server and client still both have one item, delete the item on server
and run two-way sync:
$syncevolution --run -s two-way test
after all these steps, now sever has no item and client remains one item, the
status of server and client is not synchronized.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:50 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #3 from shuangeeer <yanshuang.zheng(a)intel.com> 2009-07-23 19:50:40 ---
a typo: no "slow-way", should be "slow" :)
(In reply to comment #2)
What I have learned from these steps is that 'two-way'
doesn't behavior
normally after slow-way synchronization.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:44 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
shuangeeer <yanshuang.zheng(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|Undecided |P2
Severity|major |normal
--- Comment #4 from shuangeeer <yanshuang.zheng(a)intel.com> 2009-07-23 21:44:45 ---
Change severity to normal.
Set P2
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:41 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #5 from MarkSwanson <mark(a)ScheduleWorld.com> 2009-07-24 20:41:15 ---
(In reply to comment #3)
a typo: no "slow-way", should be "slow" :)
(In reply to comment #2)
> What I have learned from these steps is that 'two-way' doesn't behavior
> normally after slow-way synchronization.
>
I can reproduce this 100% of the time with SyncEvolution 0.9.
I can not reproduce this ever with SyncEvolution 0.8.1a.
In my brief look at why I suspect a mapping problem after the slow sync in
SyncEvolution. Reason: AAmBm creation on the server is failing with
SyncEvolution 0.9 because there is some incorrect mapping; the server tries to
get a mapping between the deleted item on the server and the existing item in
SyncEvolution 0.9 and fails.
Since this works with the Stable version of SyncEvolution 0.8.1a I'm inclined
to believe this is a bug in SyncEvolution 0.9.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:59 p.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #6 from pohly <patrick.ohly(a)intel.com> 2009-07-25 08:59:54 ---
(In reply to comment #5)
(In reply to comment #3)
> a typo: no "slow-way", should be "slow" :)
> (In reply to comment #2)
> > What I have learned from these steps is that 'two-way' doesn't
behavior
> > normally after slow-way synchronization.
> >
I can reproduce this 100% of the time with SyncEvolution 0.9.
I can not reproduce this ever with SyncEvolution 0.8.1a.
In my brief look at why I suspect a mapping problem after the slow sync in
SyncEvolution.
SyncEvolution doesn't do any mapping. How can it have a problem with it then?
Reason: AAmBm creation
What is AAmBm?
on the server is failing with
SyncEvolution 0.9 because there is some incorrect mapping; the server tries to
get a mapping between the deleted item on the server and the existing item in
SyncEvolution 0.9 and fails.
How can that failure be caused by the client?
Since this works with the Stable version of SyncEvolution 0.8.1a
I'm inclined
to believe this is a bug in SyncEvolution 0.9.
It's interesting that it doesn't occur with 0.8.1. Perhaps a comparison of the
two would show what the relevant difference is.
How can I help to solve this? I don't see what I can do without access to the
server logs,
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:40 p.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #7 from pohly <patrick.ohly(a)intel.com> 2009-07-25 09:40:24 ---
(In reply to comment #6)
(In reply to comment #5)
> (In reply to comment #3)
> > a typo: no "slow-way", should be "slow" :)
> > (In reply to comment #2)
> > > What I have learned from these steps is that 'two-way' doesn't
behavior
> > > normally after slow-way synchronization.
> > >
>
> I can reproduce this 100% of the time with SyncEvolution 0.9.
>
> I can not reproduce this ever with SyncEvolution 0.8.1a.
>
> In my brief look at why I suspect a mapping problem after the slow sync in
> SyncEvolution.
SyncEvolution doesn't do any mapping. How can it have a problem with it then?
Let me explain in more detail: SyncEvolution never keeps a mapping *after* a
sync. *During* this particular slow sync it also shouldn't have to send a
mapping, because it sends the LUID, the server matches the item and remembers
the LUID.
The only time when the client has to send a mapping is when the server adds a
new item to the client, which shouldn't be the case here.
Or did you see something else happening when you tested it?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
10:08 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #8 from pohly <patrick.ohly(a)intel.com> 2009-07-26 01:08:04 ---
I have added an automated test which covers this: testSlowSyncSemantic.
- get client A, server, client B in sync with one item
- force slow sync in A: must not duplicate items, but may update it locally
- refresh client B (in case that the item was updated)
- delete item in B and server via two-way sync
- refresh-from-server in B to check that item is gone
- two-way in A: must delete the item
Synthesis and Funambol pass it for vcard30 resp. vcard21 and text. Haven't
tried anything else, but expect it to also pass.
ScheduleWorld fails for vcard30 in the last two-way sync because it doesn't
delete the item, as described in this bug report.
ScheduleWorld fails for text in the slow sync stage because it adds a second
item to client A (bug #4596).
This will be in tonight's regular testing, so I can provide URLs for log files
tomorrow [...] Here they are:
http://runtests.syncevolution.org/2009-07-25-23-03/head-evolution-testing...
Slow sync:
http://runtests.syncevolution.org/2009-07-25-23-03/head-evolution-testing...
Two-way with missing Delete from server to client A:
http://runtests.syncevolution.org/2009-07-25-23-03/head-evolution-testing...
Mark, the code is also in the git master branch, in case you want to run the
test yourself. But as you were already able to reproduce both problems, that
might not be necessary.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:29 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #9 from MarkSwanson <mark(a)ScheduleWorld.com> 2009-07-29 21:29:44 ---
I believe I found the bug. The latest git master branch of syncevolution (and
libsynthesis) is sending this:
<Last></Last>
when it really must send something like this:
<Last>1248927454342</Last>
When the server tries to save the mapping it can't because <Last></Last>
is
invalid.
A bigger snippet:
(Sent by SyncEvolution)
<Alert>
<CmdID>3</CmdID>
<Data>201</Data>
<Item>
<Target>
<LocURI>cal2</LocURI>
</Target>
<Source>
<LocURI>./ical20</LocURI>
</Source>
<Meta>
<Anchor xmlns="syncml:metinf">
<Last></Last>
<Next>20090730T042056Z</Next>
</Anchor>
<MaxObjSize>4000000</MaxObjSize>
</Meta>
<Data></Data>
</Item>
</Alert>
<Final></Final>
The whole SyncEvolution request minus some DevInf:
<SyncML>
<SyncHdr>
<VerDTD>1.2</VerDTD>
<VerProto>SyncML/1.2</VerProto>
<SessionID>174</SessionID>
<MsgID>1</MsgID>
<Target>
<LocURI>http://quad.home2.mark/funambol/ds</LocURI>
</Target>
<Source>
<LocURI>testDevice1</LocURI>
<LocName>19</LocName>
</Source>
<Cred>
<Meta>
<Format>b64</Format>
<Type>syncml:auth-basic</Type>
</Meta>
<Data>MTk6cGFzczEyMw==</Data>
</Cred>
<Meta>
<MaxMsgSize>20000</MaxMsgSize>
<MaxObjSize>4000000</MaxObjSize>
</Meta>
</SyncHdr>
<SyncBody>
<Put>
<CmdID>1</CmdID>
<Meta>
<Type>application/vnd.syncml-devinf+wbxml</Type>
</Meta>
<Item>
<Source>
<LocURI>./devinf12</LocURI>
</Source>
<Data>
<DevInf xmlns="syncml:devinf">
...
</DevInf>
</Data>
</Item>
</Put>
<Get>
<CmdID>2</CmdID>
<Meta>
<Type>application/vnd.syncml-devinf+wbxml</Type>
</Meta>
<Item>
<Target>
<LocURI>./devinf12</LocURI>
</Target>
<Data></Data>
</Item>
</Get>
<Alert>
<CmdID>3</CmdID>
<Data>201</Data>
<Item>
<Target>
<LocURI>cal2</LocURI>
</Target>
<Source>
<LocURI>./ical20</LocURI>
</Source>
<Meta>
<Anchor xmlns="syncml:metinf">
<Last></Last>
<Next>20090730T042056Z</Next>
</Anchor>
<MaxObjSize>4000000</MaxObjSize>
</Meta>
<Data></Data>
</Item>
</Alert>
<Final></Final>
</SyncBody>
</SyncML>
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:41 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #10 from pohly <patrick.ohly(a)intel.com> 2009-07-29 23:41:15 ---
(In reply to comment #9)
I believe I found the bug. The latest git master branch of
syncevolution (and
libsynthesis) is sending this:
<Last></Last>
when it really must send something like this:
<Last>1248927454342</Last>
When the server tries to save the mapping it can't because <Last></Last>
is
invalid.
Why is an empty string invalid? The SyncML standard says that the content of
the anchor is defined by the creator of it, the peer can only do string
comparisons with it.
This could be the first sync session between the client and the server, or all
configuration data was wiped out on the client. Then there is no anchor on the
client. Sending an empty string instead of some fantasy value seems reasonable
to me.
Having said that, I'll look into sending "0" instead of "".
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:57 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #11 from pohly <patrick.ohly(a)intel.com> 2009-07-30 00:57:51 ---
(In reply to comment #10)
This could be the first sync session between the client and the
server, or all
configuration data was wiped out on the client. Then there is no anchor on the
client. Sending an empty string instead of some fantasy value seems reasonable
to me.
Having said that, I'll look into sending "0" instead of "".
A client initiated slow sync is indeed treated like a "first sync" in the
Synthesis engine, which means last local and remote anchor are cleared. I
decided to use "no local anchor" instead of "0" because that is less
likely to
be confused with a valid anchor string. This change fixes the problem.
Note that SyncEvolution 0.9 will have this workaround, but all other Synthesis
clients won't, at least not right away. This problem most likely explains why I
got duplicate contacts when syncing SyncEvolution 0.8.1 <-> ScheduleWorld <->
Synthesis iPhone and making changes on the iPhone.
I suggest that this "client anchor is not empty" assumption gets removed in the
server.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
7:44 p.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #12 from MarkSwanson <mark(a)ScheduleWorld.com> 2009-07-30 10:44:16 ---
I suggest that this "client anchor is not empty" assumption
gets removed in the
server.
Done. Unit tests work fine so far. Will push this into production tomorrow.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:30 p.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |INTEGRATED
--- Comment #13 from pohly <patrick.ohly(a)intel.com> 2009-08-02 04:30:54 ---
Integrated as beta 3 20090730 in Trunk (not Moblin:2.0!)
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:25 p.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #14 from MarkSwanson <mark(a)ScheduleWorld.com> 2009-08-02 07:25:21 ---
Done. Unit tests work fine so far. Will push this into production
tomorrow.
The patch is in production.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:25 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #15 from weibin <weibin.pan(a)intel.com> 2009-08-05 02:25:52 ---
after slow sync, scheduleworld have duplicated task.
package: syncevolution-0.8.1.99.6.09beta3。20090730-1.1.moblin2.i586
scheduleworld version: 612M
steps:
1. delete all data first, configure a service with scheduleworld template:
$syncevolution -c -y username=<username> -y password=<password> -l
scheduleworld test
2. create one task on server or client, and run a sync to make all data synced:
$syncevolution --run -s two-way test
3. now server and client both have one item, run slow sync:
$syncevolution --run -s slow test
then client have one task but scheduleworld have two task.
This is not occurred every time of slow sync, calender and task will have this
issue and addressbook seems not have this issue.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:27 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #16 from weibin <weibin.pan(a)intel.com> 2009-08-05 02:27:49 ---
create 1 calender, 1 task and 1 contact on both server and device, sync with
two-way mode and then try several times of slow sync will help to reproduce
such issue.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:56 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
--- Comment #17 from pohly <patrick.ohly(a)intel.com> 2009-08-05 02:56:54 ---
(In reply to comment #15)
after slow sync, scheduleworld have duplicated task.
This is a different kind of problem. This issue was about problems after a slow
sync, not during one. Please file a new issue.
(In reply to comment #16)
create 1 calender, 1 task and 1 contact on both server and device,
sync with
two-way mode and then try several times of slow sync will help to reproduce
such issue.
It did not occur in the latest nightly testing, which covers several slow sync
cases for all four data categories. It's likely that the kind of task or event
matters. In the new bug report, please describe exactly which properties you
set or perhaps simpler, save them as .ics and attach them.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:15 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
weibin <weibin.pan(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |5165
--- Comment #18 from weibin <weibin.pan(a)intel.com> 2009-08-05 20:15:45 ---
It still occurs today.
I have created a new bug 5165, and it block the verification of this bug.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:39 a.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
shuangeeer <yanshuang.zheng(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--- Comment #19 from shuangeeer <yanshuang.zheng(a)intel.com> 2009-08-10 20:39:21
---
The deleted items on server can be synced to client during the next two-way
after last slow sync.
Verify it with syncevolution 20090730 snapshot. (Scheduleworld - 615M)
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:37 p.m.
New subject: [Bug 4703] ScheduleWorld: delete on server can not sync to client (after doing slow sync)
http://bugzilla.moblin.org/show_bug.cgi?id=4703
Bug 4703 depends on bug 5165, which changed state.
Bug 5165 Summary: ScheduleWorld: slow sync with server will cause duplicated items.
http://bugzilla.moblin.org/show_bug.cgi?id=5165
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4252
days inactive
4284
days old
syncevolution-issues@syncevolution.org
20 comments
1 participants
participants (1)
-
bugzilla＠moblin.org