Cyrus SEEN and uidl patch

[egoitz at ramattack.net]

Hi Bron,


On Sun, 1 Apr 2012 22:45:48 +1000, Bron Gondwana wrote:
On Sun, Apr 01, 2012 at 11:08:36AM +0100, Jeroen van Meeuwen (Kolab
> Systems) wrote:
>> >I'm running an ISP environment with Cyrus 2.3.18.
>>
>> Given that Cyrus IMAP 2.3 is... well... rather old, it is maintained
>> by only a small group of people having volunteered to do so. The
>> main focus for the project is Cyrus IMAP 2.4, and future releases
>> currently in development, so a question that pops up in my mind is -
>> can this issue be reproduced in Cyrus IMAP 2.4.14, or even GIT
>> master (future 2.5)?
>
> No to the main issue, because per-user seen is stored in the mailbox,
> so these seen strings don't exist.

the user seen (AFAIK) is stored in 
imap/domain/(letter)/(letterdomain)/user/*.seen If I'm not wrong... and 
I have been able to reproduce it... by injecting a big number of mails 
with Postal to one mailbox and later... marking them as read (some yes 
some no.... randomly).... there's a moment in which the replication gets 
stuck when the line of the mailbox grows..... remember Bron, I have 
patched Cyrus now... (and before writting my own proposed patch) with 
http://www.irbs.net/internet/info-cyrus/0602/att-0330/pop3_uidl.diff 
with modifies /lib/prot.c and it's prot_printf function... changing 
significantly the output in prot_write....

take a look to... at sync_support.c... I think this would be affected 
(for example) by the patch proposed on the url I told before....


  void sync_printastring(struct protstream *out, const char *s)
{
.
.
.
.
.

    /* if it's too long, literal it */
     if (*p || len >= 1024) {
	prot_printf(out, "{" SIZE_T_FMT "+}\r\n%s", strlen(s), s);
     } else {
	prot_printf(out, "\"%s\"", s);
     }
}

because prot_printf won't understand the %s as it should... you're 
saying different ways to prot_printf which in the other way... wouldn't 
really "understand" removing the while loop... in prot_printf.....


>
> And I'm fairly sure the replication protocol won't mind arbitrarily
> long SEEN strings either, because it uses a different method.
>


Then Bron, which would you think could be the cause?. Please if you 
have another idea or suspect let me know... for checking... it's 
important for me to fix this issue (and at this moment... maintaining 
cyrus version)...


> But - I have no objection to fixing the issue in 2.3.x.

That would be nice Bron!!... you could reproduce it the way told...  
and you can later solve with my proposed version of this patch....


>
> Bron.

Egoitz.