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

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.

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.

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

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.

But if you keep the existing timestamp would not the updated contact 
be duplicated on the next sync with the same device?
Thank you!

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.

The Log is attached, you can see on line 95 that the saved timestamp is 0.

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.

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