6.0.0-beta1
7/10/25

[#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 11/09/2011 (4992 days ago)
Due
Updated 11/14/2011 (4987 days ago)
Assigned 11/13/2011 (4988 days ago)
Resolved 11/13/2011 (4988 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
11/14/2011 01:11:01 PM 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

11/13/2011 03:39:52 PM Michael Rubinsky State ⇒ Resolved
 
11/13/2011 02:29:14 PM 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.

11/13/2011 01:52:52 AM 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.
11/13/2011 01:51:05 AM 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
11/09/2011 08:06:50 PM 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.
11/09/2011 08:00:07 PM 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!

11/09/2011 07:51:56 PM 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.
11/09/2011 07:36:41 PM 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.
11/09/2011 06:50:33 PM Michael Rubinsky Comment #2
State ⇒ Feedback
Assigned to Michael Rubinsky
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.
11/09/2011 06:26:43 PM joniw (at) t-online (dot) de Comment #1
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ Duplicated contacts when using ActiveSync on Android
Type ⇒ Bug
Queue ⇒ Synchronization
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