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 |
Thanks a million (both to Jonathan for filing the bug and Michael for
resolving it).
-- Seth Green
New Attachment: ActiveSync.txt
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.
State ⇒ Feedback
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.
Load the last sync timestamp into the default value of the current
sync timestamp.
Fixes (?)
Bug: 10731If 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
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.
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.
be duplicated on the next sync with the same device?
State ⇒ Assigned
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.
New Attachment: ActiveSyncLog.txt
for changes. If its not, something else is going on. Sounds like
maybe the syncstate is being reset at some point for some reason.
State ⇒ Feedback
Assigned to Michael Rubinsky
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.
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ Duplicated contacts when using ActiveSync on Android
Type ⇒ Bug
Queue ⇒ Synchronization
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