[Tickets #12523] Re: AS: mix of unix timestamp and modseq breaks sync

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12523
------------------------------------------------------------------------------
  Ticket             | 12523
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | AS: mix of unix timestamp and modseq breaks sync
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
-State              | Unconfirmed
+State              | Assigned
-Priority           | 1. Low
+Priority           | 2. Medium
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-08-01 15:06) wrote:

It's actually be a problem with writing the change when the client's  
change (add) is initially imported. The syncMapTable stores either TS  
or MODSEQ value in the syncmodtime field. The code doesn't care what  
the value represents, as long as it's a value that increments with time.

The question, then, is why does $change['mod'] contain a timestamp in  
Horde_ActiveSync_State_Sql::updateState() and not the current modseq  
value for that particular collection? It looks like the problem is in  
Horde_Core_ActiveSync_Driver::changeMessage() we unconditionally  
return the current time() as the mod value. We need to poll the  
backend to find out if it supports modsequences and use them, similar  
to what is done in the history related api calls.