6.0.0-git
2019-04-21

[#10731] Duplicated contacts when using ActiveSync on Android
Summary Duplicated contacts when using ActiveSync on Android
Queue Synchronization
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester joniw (at) t-online (dot) de
Created 2011-11-09 (2720 days ago)
Due
Updated 2011-11-14 (2715 days ago)
Assigned 2011-11-13 (2716 days ago)
Resolved 2011-11-13 (2716 days ago)
Milestone
Patch No

History
2011-11-14 13:11:01 registrations (at) baruchgreen (dot) net Comment #10 Reply to this comment
FYI.  I was having similar problems and this also fixed it for me.

Thanks a million (both to Jonathan for filing the bug and Michael for 
resolving it).

-- Seth Green

2011-11-13 15:39:52 Michael Rubinsky State ⇒ Resolved
 
2011-11-13 14:29:14 joniw (at) t-online (dot) de Comment #9
New Attachment: ActiveSync.txt Download
Reply to this comment
Can you try what I just pushed?
That patch seems to fix it. As you can see in the attached log now 
only the modified contact is returned on the next sync but the client 
recognizes that it was the changed contact and does not duplicate it.

Thanks for the quick fix.

2011-11-13 01:52:52 Michael Rubinsky Comment #8
State ⇒ Feedback
Reply to this comment
Can you try what I just pushed?

I can't fully test, since none of my clients do not send the 
GETCHANGES entity. If I comment out the code, essentially ignoring it, 
I don't get the same behavior as you, though I do see some other 
weird, PING related, issues.
2011-11-13 01:51:05 Git Commit Comment #7 Reply to this comment
Changes have been made in Git for this ticket:

Load the last sync timestamp into the default value of the current 
sync timestamp.
Fixes (?) Bug: 10731

If a client sends changes without requesting server changes, we must 
persist the
existing last sync timestamp. Clearing it will result in all kinds of errors
such as possible duplicate entries (though the client *should* 
recognize the UID
of the duplicate entry and ignore it), and mis-matched PING states.

  1 files changed, 4 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/565bf2f097cc814c88a48127305410b70d34156c
2011-11-09 20:06:50 Michael Rubinsky Comment #6 Reply to this comment
It *shouldn't*. We track UIDs and times of incoming changes just for 
this purpose. Though the code/timing of the check and garbage 
collection might have to be tweaked.

If we increase the timestamp without polling for changes on the server 
side,we will never see any changes that might occurred after the last 
GETCHANGES up to the new timestamp...and we can't send serverside 
changes without being asked to do so.
2011-11-09 20:00:07 joniw (at) t-online (dot) de Comment #5 Reply to this comment
Ah. I misread your original post. The s from an incoming change 
only. All the other clients I've tested seem to send a getchanges 
with all incoming sync requests. We'll have to not save a *new* 
timestamp here, but rather persist the existing one.
But if you keep the existing timestamp would not the updated contact 
be duplicated on the next sync with the same device?
I'll look at this next time I'm in front of my computer.
Thank you!

2011-11-09 19:51:56 Michael Rubinsky Comment #4
State ⇒ Assigned
Reply to this comment
Ah. I misread your original post. The s from an incoming change only. 
All the other clients I've tested seem to send a getchanges with all 
incoming sync requests. We'll have to not save a *new* timestamp here, 
but rather persist the existing one.

I'll look at this next time I'm in front of my computer.
2011-11-09 19:36:41 joniw (at) t-online (dot) de Comment #3
New Attachment: ActiveSyncLog.txt Download
Reply to this comment
Please provide a complete sync log. See http://wiki.horde.org/ActiveSync
The Log is attached, you can see on line 95 that the saved timestamp is 0.
The client *should* be sending the GETCHANGES  tag if it's asking 
for changes.  If its not, something else is going on. Sounds like 
maybe the syncstate is being reset at some point for some reason.
2011-11-09 18:50:33 Michael Rubinsky Comment #2
Assigned to Michael Rubinsky
State ⇒ Feedback
Reply to this comment
Please provide a complete sync log. See http://wiki.horde.org/ActiveSync

The client *should* be sending the GETCHANGES  tag if it's asking for 
changes.  If its not, something else is going on. Sounds like maybe 
the syncstate is being reset at some point for some reason.
2011-11-09 18:26:43 joniw (at) t-online (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Duplicated contacts when using ActiveSync on Android
Queue ⇒ Synchronization
Milestone ⇒
Patch ⇒ No
Reply to this comment
Hello

When i change a contact on my DesireHD after some time all contacts 
are duplicated on my phone.
I use ActiveSync to sync the contacts. I just look into the logs and 
it looks like when the update ist done the timestamp of the last sync 
is set to 0. After the update the phone syncs again and the server 
returns all contacts as the timestamp is 0.

After looking into the code i think the timestamp should be set 
somewhere in ActiveSync/Request/Sync.php around line 390. The 
timestamp is onyl set if the "getchanges" Tag is sent from the syncing 
device(line 393 and 397, the init method calls GetChanges on the state 
machine ins ActiveSync/Sync.php).

If you need any further infotmation just ask.

with regards

Jonathan

Saved Queries