[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              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-08-07 20:57) wrote:

>>> Horde_ActiveSync_Connector_Importer::importMessageDeletion() looks
>>> affected, too.
>>
>> It uses the same Horde_Core_ActiveSync_Driver::changeMethod call so
>> this will be fixed by the same change.
>
> IMHO
>
> Importer::importMessageDeletion() will still write time() to $change['mod'],
> Driver::changeMessage() is not used in this code path. Or is it?
>
> I'm 99% sure it will go wrong though I haven't tested the new code yet.

Eh. You are right of course. I have no idea what I was looking at when  
I said that =)

> Sorry, I think I misread this somehow. The last time I read it,
> the state update was before the moveMessage() call :)
>
> UPDATE: I think I understand why I confused it: The importMessageDeletion()
> _first_ updates the state and then does the deletion. In case the  
> "backend" deletion
> times out, the state is already updated. Is that intentional?

Reading my comments, it seems like I did it on purpose, but to be  
honest, I'm not sure that the points I make are really necessary. I'll  
have to revisit this.


> I've grepped the codebase for 'mod' usage and found
> two other places that look "interesting". Would be nice
> if you could check them for correctness:

Both of those are used during foldersyncs, not collection syncs. For  
folder syncs, the only change we care about for an existing folder is  
a change in the name of the folder. We don't track folder name changes  
in history, so the only way to know it has changed is to compare the  
client's version of the name and the server's version of the name. We  
use the name as the 'mod' value since it's the only thing that changes  
with regard to a folder name.