[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         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  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
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-08-07 21:11) wrote:

>> 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 =)

:)

We should replace the time() call in importMessageMove(), too.
Even though moving groupware objects is currently unsupported,
it will be a PITA to debug in the future if we ever support it.

>> 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'll have a look at the git history tomorrow, too.
May be there's a hint in there.

>> 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.

Thanks for checking!

Thomas