Hi Peter,

----- Nachricht von Peter <horde@peter-b.org> ---------
   Datum: Sun, 14 Feb 2016 17:36:14 +0000
     Von: Peter <horde@peter-b.org>
Betreff: Re: [horde] [Same Problem] ActiveSync problem with contacts  
disappeared
      An: horde@lists.horde.org


> On 28/12/2015 18:38, Michael J Rubinsky wrote:
>> Quoting Peter <Horde@peter-b.org>:
>>
>>> No, the test log I attached only had entries for the sync that  
>>> took place during the addition and disappearance of the contact on  
>>> the device.
>>
>> If the contact disappeared during the time included in your log,  
>> then it's not anything Horde did. There was NO traffic from the  
>> device->Horde to show even the attempted addition of the contact on  
>> the phone.
>>
>
> Apologies for being away from this discussion for so long but I've  
> basically been trying to find the cause of this in-between "real  
> life". I've spent an inordinate amount of time on it, fiddling with  
> Horde EAS library code, trying different versions of various  
> components in the chain, comparing results from different systems  
> and devices. I've let this problem push back the rollout of the new  
> server by nearly 3 weeks.
>
> I'm writing this update for anyone else that comes across this  
> problem - I can't believe I'm the only one, though I suspect it may  
> only affect a small number of users - though apologies in advance, I  
> didn't find a solution.

I believe I have similar issue with calender entries, but couldn't get  
the time to investigate that.

Here it's only one phone afaik that produces the problem, but it most  
possibly not related to your problem. Just wanted to mention that.

Best,
Andreas


> I can confirm that on a basic build of an Ubuntu Trusty server with  
> nothing but Horde requirements and Horde itself, this problem occurs  
> on Android 5.0.2 and 6.0.1 (no surprise, no real difference in the  
> underlying exchange library), on 3 different devices and 2 emulators  
> using the stock email client exchange libraries. Those same devices  
> can all connect to and sync with my existing Horde server with no  
> errors. I've tried several different iterations of the server,  
> having built a few internally in virtual machines with various  
> different configurations, though all based on Trusty.
>
> I've determined that it's something to do with the data sent by  
> Horde during the synchronisation sequence (as in I've tweaked the  
> EAS code to send the EAS packets with no actual data in them and  
> nothing gets erased anywhere) but when the data is sent the problem  
> occurs.
>
> After having had so much time elapse on this and put in so many  
> hours I balked at digging further into the code that constructs the  
> data to find out what specifically was causing the problem. The  
> reason? In less than a day I found an alternative solution to Horde  
> that just works. Admittedly, the solution is not as feature-rich  
> overall as Horde but has more than all the features that my (100 or  
> so) users are going to want.
>
> Sorry - as much as I love Horde (I've been using it since about  
> 1996, I think) and want to push it as a solution I simply can't  
> justify spending any more time on it. EAS aside it works, but having  
> had users using EAS for a couple of years I can't now take it away  
> from them pending a resolution to this particular problem and I need  
> to roll out the new server sooner rather than later.
>
> What I can tell you is that I suspect it's a problem with the  
> Android exchange libraries not handling something unusual in the  
> data received in a sync packet from Horde, i.e. it's not getting the  
> data in a specific field with the expected type or within the  
> expected range and so is throwing and exception, then behaving badly  
> afterwards and losing data in the process.
>
> I suspect that the duff data is the result of a misconfiguration on  
> the server rather than because of a code-bug in Horde; the data  
> being sent by Horde that relies on this configuration is malformed,  
> and the exchange library isn't handling the malformed data.
>
> Whilst I think it's more than likely it's an Android code issue it  
> seems that the alternative solution I've found doesn't cause this  
> problem, either because it's refusing to send malformed data despite  
> the server misconfiguration, or it simply doesn't use whatever field  
> is causing the problem.
>
> If I get time I'll come back to this, but having found an  
> alternative it's definitely a low-priority issue for me now.
>
> Peter.


----- Ende der Nachricht von Peter <horde@peter-b.org> -----


