[Tickets #13825] Re: Remi PHP update to 5.5.21-1 results in constant resyncing

[noreply at bugs.horde.org]

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

Ticket URL: https://bugs.horde.org/ticket/13825
------------------------------------------------------------------------------
  Ticket             | 13825
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Remi PHP update to 5.5.21-1 results in constant
                     | resyncing
  Queue              | Synchronization
  Version            | FRAMEWORK_5_2
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael M Slusarz <slusarz at horde.org>, Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2015-02-04 18:00) wrote:

>> C: 31 UID SEARCH RETURN (ALL COUNT) HEADER MESSAGE-ID
>> <00d701d01f08$6f76a3f0$4e63ebd0$@amusing.de> UID 0:215
>> S: 31 BAD Error in IMAP command UID SEARCH: Invalid UID messageset
>
> Obviously, 0 is not allowed.  Imap code doesn't do assert checking  
> for this situation (it probably should).  But that 0 has to come  
> from the calling code.

I can't reproduce this. The ids provided to the method that calls this  
search routine come from the list of uids provided from the IMAP  
server. There is an array_diff that removes uids that we know have  
since vanished. The only thing I can think of is that this is a  
secondary effect to the STATUS error, since the HIGHESTMODSEQ value  
returned from that call is used to determine if we need to treat the  
server as MODSEQ/CONDSTORE capable or not. If a server that has been  
treated as MODSEQ is suddenly treated as not, that will cause all  
sorts of issues with UID handling since we store different data  
structures for each.

I can add code to attempt to detect this "switch", but it won't solve  
the underlying problem and will only cause things to fail in a  
different, more controlled way.


>> C: 31 STATUS "INBOX.!  Astrid""" (MESSAGES UIDNEXT UIDVALIDITY  
>> HIGHESTMODSEQ)
>
> Can't reproduce.  I have no idea where those extra quotes are coming  
> from, since if they actually did exist in the input they would be  
> escaped.
>
> Considering that nothing has changed in regards to either Id  
> generation or String escaping lately, this doesn't seem to be  
> anything related to Imap_Client code.  (Whitespace is irrelevant - I  
> have hundreds of mailboxes with whitespace and they display  
> perfectly fine.)

I can't reproduce either. Not in ActiveSync unit testing, local client  
testing, or IMP/IMAP testing.  You are going to need to figure out  
where the extra quotes are coming from in the mailbox name. As a  
start, you can try running the following code in Horde's PHP shell  
(Administration->PHPSHELL):

$f = new Horde_Core_ActiveSync_Imap_Factory();
var_dump($f->getMailboxes(true));

and see what type or values are returned.