Re: Cyrus SEEN and uidl patch
They both have been tested under FreeBSD 9.0 with 2.3.18_1 port of FreeBSD. Best regards :) El Dom, 1 de Abril de 2012, 10:38 pm, ego...@ramattack.net escribió: > Good night, > > > Well people, have been working a little last hour... I think I got > something :) :) > > I think I have the patches ready :) :) > > > Have modified the prot_printf function minimally for being able to work > with pop3 UIDL for Outlook. The pop3d.c is the same... but the patch for > /lib/prot.c is now more beautiful :) :). > > > Tell me please what do you think... I have tested and seems to work fine > :)... perhaps it needs more time of tests... but... seems to work well > and don't think it's going to cause any problems... > > I await some answer from you :) > > > Best regards, > > >
Re: Cyrus SEEN and uidl patch
Good night, Well people, have been working a little last hour... I think I got something :) :) I think I have the patches ready :) :) Have modified the prot_printf function minimally for being able to work with pop3 UIDL for Outlook. The pop3d.c is the same... but the patch for /lib/prot.c is now more beautiful :) :). Tell me please what do you think... I have tested and seems to work fine :)... perhaps it needs more time of tests... but... seems to work well and don't think it's going to cause any problems... I await some answer from you :) Best regards, parche-pop3d.c Description: Binary data parche-prot.c Description: Binary data
Re: Cyrus SEEN and uidl patch
> > I guess the issue is that the original patch replaces prot_printf > implementation to rely on vsnprintf with a fixed-size (2048 bytes) buffer. > So if any part of cyrus has to write a string (%s) which size is over > 2048 characters (actually less than that, since there is the nul-byte > ending and possibly extra data to take into account in the format), the > output is truncated. This is to compare to the original code of > prot_printf which sends the string as-is when if parses '%s' in the > format. > > The revised version of the patch is not really ideal either, since it > introduces a second prot_printf function only to take care of the root UIDL > issue related to Outlook. But it shouldn't break nothing isn't it?... perhaps it's not the most "beautiful" way of solving the problem... but Julien, don't you think it could solve the problem?... well I have noticed have forgotten to write the function prototype too... although has worked... I assume gcc is more clever than we normally think :)... but apart of this and setting the prototype properly... it should work properly, don't you think?? The current code do already use snprintf to > format some data (integers etc), so I would say that extending it to > recognize formats such as '%#.#d' (that is integer and the likes with > minimum field width and/or precision) could be a solution to have the > Outlook UIDL patch use the > prot_printf function without breaking anything else. But of course it's > easier said than done ;) I will try to write this... yep Yeah... really the ideal solution would be to recognize those formats through prot_printf > > Julien > >
Re: Cyrus SEEN and uidl patch
Le 01/04/2012 14:45, Bron Gondwana a écrit : 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. And I'm fairly sure the replication protocol won't mind arbitrarily long SEEN strings either, because it uses a different method. But - I have no objection to fixing the issue in 2.3.x. Bron. I guess the issue is that the original patch replaces prot_printf implementation to rely on vsnprintf with a fixed-size (2048 bytes) buffer. So if any part of cyrus has to write a string (%s) which size is over 2048 characters (actually less than that, since there is the nul-byte ending and possibly extra data to take into account in the format), the output is truncated. This is to compare to the original code of prot_printf which sends the string as-is when if parses '%s' in the format. The revised version of the patch is not really ideal either, since it introduces a second prot_printf function only to take care of the root UIDL issue related to Outlook. The current code do already use snprintf to format some data (integers etc), so I would say that extending it to recognize formats such as '%#.#d' (that is integer and the likes with minimum field width and/or precision) could be a solution to have the Outlook UIDL patch use the prot_printf function without breaking anything else. But of course it's easier said than done ;) Julien
Re: Cyrus SEEN and uidl patch
On 2012-04-01 14:09, ego...@ramattack.net wrote: Good morning Jeroen, On Sun, 01 Apr 2012 11:08:36 +0100, Jeroen van Meeuwen (Kolab Systems) wrote: On 2012-04-01 10:25, ego...@ramattack.net wrote: Good morning, Good morning, Not speaking to the code changes itself, I have a couple of suggestions / questions. If you are familiar with GIT, could you please clone the git repository[1] and create a patch(-set) with git-format-patch? In case you're not all too familiar with GIT, you could, for example: $ git clone git://git.cyrusimap.org/git/cyrus-imapd $ cd cyrus-imapd $ git checkout cyrus-imapd-2.3 $ git checkout -b dev/pop3_uidl-patch (...make some changes...) $ git commit /path/to/changed/files (...make some more changes...) $ git commit /path/to/changed/files $ git format-patch origin/cyrus-imapd-2.3 sorry not very familiar with git more with cvsd and svn... but apart from this : /usr/local/git/bin/git clone git://git.cyrusimap.org/git/cyrus-imapd Cloning into 'cyrus-imapd'... fatal: The remote end hung up unexpectedly this is the answer I'm obtaining I'm sorry, that's my mistake. The URL I intended to refer you to is: git://git.cyrusimap.org/cyrus-imapd I had one 'git/' too many. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Cyrus SEEN and uidl patch
%cyr_dbtool /expert/correo/imap/domain/e/egoitz.com/user/e/egoitz.seen skiplist show 04409b4d4f77894d1 1333236088 8127 1333236383 25,84,88,96:97,104,120,130,147,149,152,158:160,198,204,218,263,273,333,335,337,341,355,382:383,420,441,458,467,509,512,514,530,545,548,594,601,616,641,661,666,681,703,716,742,786,790,794:795,812,819,824,845,847,859,865,878,889,891,893:894,899,905,934,953,984,997,1002,1009,1024,1033,1045,1055,1068,1070,1123,1126,1137,1142,1165,1170,1175:1176,1179,1195,1197,1211,1221,1230,1236,1261,1263,1271,1275,1299,1314,1345,1377,1381,1417,1421,1428,1439,1443,1451,1454,1462,1470,1476,1478,1515,1526,1540,1564:1566,1573,1593,1608,1626,1628,1661,1674,1697,1699,1702,1713,1736,1748,1772,1775,1781,1797,1830,1834,1865,1870:1871,1888,1910,1923,1930,1932,1935,1940,1950,1963,1974,2005,2009,2011,2019,2027,2044,2058,2069,2073,2079,2095,2101:2102,2119,2122,2134,2137,2141,2143,2209,2213,2220,2223,2237,2247,2253,2267,2271,2287,2293,2313,2331,2334,2336,2338,2356,2370,2375,2387,2411,2431,2451,2457,2478,2493,2517,2520,2550,2556,2572,2575,2594,2596,2600,2605,2658:2659,2708,2715,2732,2738,2766,2778,2795,2817, 28 30,2885, 2889,2904,2911,2917,2920,2930,2940,2953,2955,2962,2970:2971,2985,2991,3014,3031,3035,3038:3040,3091,3096,3147,3154,3171,3180,3183,3191,3199,3219,3221,3225,3227,3230,3235,3254,3264,3273,3280,3304,3343,3371,3375,3406,3414,3419,3425,3445,3451,3463,3489,3492,3499,3525,3556,3564,3604,3636,3643,3665,3667,3670,3691:3692,3746:3747,3797,3801,3803,3811,3852,3872,3883,3886,3907,3923,3930,3960,3963,3993,4020,4036,4043,4045,4105,4142,4149,4152,4159,4172,4218,4220,4257,4275,4309,4363,4365,4369,4371,4393,4400,4434,4463,4481,4515,4554,4581,4585,4591,4600,4641,4663,4710,4713,4721,4767,4792,4818,4872,4898,4928,4961,4970:4971,4977,4979:4981,4983,5009,5014,5037,5075:5076,5105,5152,5156,5165,5177,5193,5208,5241,5261,5275,5281,5296,5298,5313,5321,5328,5334,5363,5392,5395,5398,5401,5408,5427,5440,5453,5466,5483,5520,5527,5537,5549,5597,5602:5603,5608,5613,5652,5683,5688,5692,5719,5730,5747,5752:5753,5764,5804,5845,5848,5860,5887,5919:5920,5937,5950,5963,5974,5980,6008,6017,6031:6032,6043,6051:605 2, 6054,607 0,6143,6180,6194,6273,6307,6327,6359,6384,6389,6405,6407,6418,6421,6435,6443,6452,6462,6480,6488,6499,6518,6534,6556,6566,6576,6588,6603,6606,6616,6618,6651,6691,6736,6772,6820,6840,6844,6858,6860,6864,6880,6907,6913,6921,6932,6969,6977,6990,6996,7014:7015,7030,7034,7042,7052,7084,7087,7095,7109,7142,7151,7157,7162,7176:7177,7187,7194,7199,7215,7247,7256,7275,7282,7325,7331,7340:7341,7346,7349:7350,7376,7383:7384,7403,7425,7479,7566,7571,7578,7603,7611,7623,7648,7688:7689,7700,7728,7758,7766,7781,7794,7806,7815,7819,7851,7854,7863:7864,7887,7915,7919,7929:7930,7941,7981,7985 60fce00e4f778f59 1 1333235732 31 1333235973 1,3:4,8:9,12,14:15,22:28,31 6dd5e44d4f778f491 1333236161 1 1333235642 1 (like the first one... of course) But - I have no objection to fixing the issue in 2.3.x. Bron. Really this is the skiplist %cyr_dbtool /expert/correo/imap/domain/e/egoitz.com/user/e/egoitz.seen skiplist show 04409b4d4f77894d 1 1333236088 8127 1333236383 25,84,88,96:97,104,120,130,147,149,152,158:160,198,204,218,263,273,333,335,337,341,355,382:383,420,441,458,467,509,512,514,530,545,548,594,601,616,641,661,666,681,703,716,742,786,790,794:795,812,819,824,845,847,859,865,878,889,891,893:894,899,905,934,953,984,997,1002,1009,1024,1033,1045,1055,1068,1070,1123,1126,1137,1142,1165,1170,1175:1176,1179,1195,1197,1211,1221,1230,1236,1261,1263,1271,1275,1299,1314,1345,1377,1381,1417,1421,1428,1439,1443,1451,1454,1462,1470,1476,1478,1515,1526,1540,1564:1566,1573,1593,1608,1626,1628,1661,1674,1697,1699,1702,1713,1736,1748,1772,1775,1781,1797,1830,1834,1865,1870:1871,1888,1910,1923,1930,1932,1935,1940,1950,1963,1974,2005,2009,2011,2019,2027,2044,2058,2069,2073,2079,2095,2101:2102,2119,2122,2134,2137,2141,2143,2209,2213,2220,2223,2237,2247,2253,2267,2271,2287,2293,2313,2331,2334,2336,2338,2356,2370,2375,2387,2411,2431,2451,2457,2478,2493,2517,2520,2550,2556,2572,2575,2594,2596,2600,2605,2658:2659,2708,2715,2732,2738,2766,2778,2795,2817,28 30,2885, 2889,2904,2911,2917,2920,2930,2940,2953,2955,2962,2970:2971,2985,2991,3014,3031,3035,3038:3040,3091,3096,3147,3154,3171,3180,3183,3191,3199,3219,3221,3225,3227,3230,3235,3254,3264,3273,3280,3304,3343,3371,3375,3406,3414,3419,3425,3445,3451,3463,3489,3492,3499,3525,3556,3564,3604,3636,3643,3665,3667,3670,3691:3692,3746:3747,3797,3801,3803,3811,3852,3872,3883,3886,3907,3923,3930,3960,3963,3993,4020,4036,4043,4045,4105,4142,4149,4152,4159,4172,4218,4220,4257,4275,4309,4363,4365,4369,4371,4393,4400,4434,4463,4481,4515,4554,4581,4585,4591,4600,4641,4663,4710,4713,4721,4767,4792,4818,4872,4898,4928,4961,4970:4971,4977,4979:4981,4983,5009,5014,5037,5075:5076,5105,5152,5156,5165,5177,5193,5208,5241,5261,5275,5281,5296,5298,5313,5321,5328,5334,5363,5392,5395,5398,5401,5408,5427,5440,5453,5466,5483,5520,5527,5537,5549,5597,5602:5603,5608,5613,5652,5683,5688,5
Re: Cyrus SEEN and uidl patch
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. And I'm fairly sure the replication protocol won't mind arbitrarily long SEEN strings either, because it uses a different method. Not arbitrarily just when you have a seen like this... and a record of this size... %cyr_dbtool /expert/correo/imap/domain/e/egoitz.com/user/e/egoitz.seen skiplist show 04409b4d4f77894d 1 1333236088 8127 1333236383 25,84,88,96:97,104,120,130,147,149,152,158:160,198,204,218,263,273,333,335,337,341,355,382:383,420,441,458,467,509,512,514,530,545,548,594,601,616,641,661,666,681,703,716,742,786,790,794:795,812,819,824,845,847,859,865,878,889,891,893:894,899,905,934,953,984,997,1002,1009,1024,1033,1045,1055,1068,1070,1123,1126,1137,1142,1165,1170,1175:1176,1179,1195,1197,1211,1221,1230,1236,1261,1263,1271,1275,1299,1314,1345,1377,1381,1417,1421,1428,1439,1443,1451,1454,1462,1470,1476,1478,1515,1526,1540,1564:1566,1573,1593,1608,1626,1628,1661,1674,1697,1699,1702,1713,1736,1748,1772,1775,1781,1797,1830,1834,1865,1870:1871,1888,1910,1923,1930,1932,1935,1940,1950,1963,1974,2005,2009,2011,2019,2027,2044,2058,2069,2073,2079,2095,2101:2102,2119,2122,2134,2137,2141,2143,2209,2213,2220,2223,2237,2247,2253,2267,2271,2287,2293,2313,2331,2334,2336,2338,2356,2370,2375,2387,2411,2431,2451,2457,2478,2493,2517,2520,2550,2556,2572,2575,2594,2596,2600,2605,2658:2659,2708,2715,2732,2738,2766,2778,2795,2817,28 30,2885, 2889,2904,2911,2917,2920,2930,2940,2953,2955,2962,2970:2971,2985,2991,3014,3031,3035,3038:3040,3091,3096,3147,3154,3171,3180,3183,3191,3199,3219,3221,3225,3227,3230,3235,3254,3264,3273,3280,3304,3343,3371,3375,3406,3414,3419,3425,3445,3451,3463,3489,3492,3499,3525,3556,3564,3604,3636,3643,3665,3667,3670,3691:3692,3746:3747,3797,3801,3803,3811,3852,3872,3883,3886,3907,3923,3930,3960,3963,3993,4020,4036,4043,4045,4105,4142,4149,4152,4159,4172,4218,4220,4257,4275,4309,4363,4365,4369,4371,4393,4400,4434,4463,4481,4515,4554,4581,4585,4591,4600,4641,4663,4710,4713,4721,4767,4792,4818,4872,4898,4928,4961,4970:4971,4977,4979:4981,4983,5009,5014,5037,5075:5076,5105,5152,5156,5165,5177,5193,5208,5241,5261,5275,5281,5296,5298,5313,5321,5328,5334,5363,5392,5395,5398,5401,5408,5427,5440,5453,5466,5483,5520,5527,5537,5549,5597,5602:5603,5608,5613,5652,5683,5688,5692,5719,5730,5747,5752:5753,5764,5804,5845,5848,5860,5887,5919:5920,5937,5950,5963,5974,5980,6008,6017,6031:6032,6043,6051:6052, 6054,607 0,6143,6180,6194,6273,6307,6327,6359,6384,6389,6405,6407,6418,6421,6435,6443,6452,6462,6480,6488,6499,6518,6534,6556,6566,6576,6588,6603,6606,6616,6618,6651,6691,6736,6772,6820,6840,6844,6858,6860,6864,6880,6907,6913,6921,6932,6969,6977,6990,6996,7014:7015,7030,7034,7042,7052,7084,7087,7095,7109,7142,7151,7157,7162,7176:7177,7187,7194,7199,7215,7247,7256,7275,7282,7325,7331,7340:7341,7346,7349:7350,7376,7383:7384,7403,7425,7479,7566,7571,7578,7603,7611,7623,7648,7688:7689,7700,7728,7758,7766,7781,7794,7806,7815,7819,7851,7854,7863:7864,7887,7915,7919,7929:7930,7941,7981,7985 60fce00e4f778f591 1333235732 31 1333235973 1,3:4,8:9,12,14:15,22:28,31 6dd5e44d4f778f491 1333236161 1 1333235642 1 (like the first one... of course) But - I have no objection to fixing the issue in 2.3.x. Bron.
Re: Cyrus SEEN and uidl patch
Good morning Jeroen, On Sun, 01 Apr 2012 11:08:36 +0100, Jeroen van Meeuwen (Kolab Systems) wrote: On 2012-04-01 10:25, ego...@ramattack.net wrote: Good morning, Good morning, Not speaking to the code changes itself, I have a couple of suggestions / questions. If you are familiar with GIT, could you please clone the git repository[1] and create a patch(-set) with git-format-patch? In case you're not all too familiar with GIT, you could, for example: $ git clone git://git.cyrusimap.org/git/cyrus-imapd $ cd cyrus-imapd $ git checkout cyrus-imapd-2.3 $ git checkout -b dev/pop3_uidl-patch (...make some changes...) $ git commit /path/to/changed/files (...make some more changes...) $ git commit /path/to/changed/files $ git format-patch origin/cyrus-imapd-2.3 sorry not very familiar with git more with cvsd and svn... but apart from this : /usr/local/git/bin/git clone git://git.cyrusimap.org/git/cyrus-imapd Cloning into 'cyrus-imapd'... fatal: The remote end hung up unexpectedly this is the answer I'm obtaining And send the resulting -*.patch files as an attachment to an email, but better yet, a Bugzilla[2] ticket. So I'm not able to generate this patch... unless now... :) If you would be able to do that, that'd be great. 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. Don't you think perhaps replication staff is more widely tested in 2.3.last? 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)? Kind regards, Jeroen van Meeuwen Thanks a lot Jeroen, Best regards, [1] http://git.cyrusimap.org/cyrus-imapd [2] https://bugzilla.cyrusimap.org
Re: Cyrus SEEN and uidl patch
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.
Re: Cyrus SEEN and uidl patch
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. And I'm fairly sure the replication protocol won't mind arbitrarily long SEEN strings either, because it uses a different method. But - I have no objection to fixing the issue in 2.3.x. Bron.
Re: Cyrus SEEN and uidl patch
On 2012-04-01 10:25, ego...@ramattack.net wrote: Good morning, Good morning, Not speaking to the code changes itself, I have a couple of suggestions / questions. If you are familiar with GIT, could you please clone the git repository[1] and create a patch(-set) with git-format-patch? In case you're not all too familiar with GIT, you could, for example: $ git clone git://git.cyrusimap.org/git/cyrus-imapd $ cd cyrus-imapd $ git checkout cyrus-imapd-2.3 $ git checkout -b dev/pop3_uidl-patch (...make some changes...) $ git commit /path/to/changed/files (...make some more changes...) $ git commit /path/to/changed/files $ git format-patch origin/cyrus-imapd-2.3 And send the resulting -*.patch files as an attachment to an email, but better yet, a Bugzilla[2] ticket. If you would be able to do that, that'd be great. 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)? Kind regards, Jeroen van Meeuwen [1] http://git.cyrusimap.org/cyrus-imapd [2] https://bugzilla.cyrusimap.org -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Cyrus SEEN and uidl patch
Good morning, I'm running an ISP environment with Cyrus 2.3.18. I have seen, we have some problems when sync_client tries to do a SEEN from some mailboxes. First of all, say that we had to patch Cyrus IMAP with this proposed patch http://www.irbs.net/internet/info-cyrus/0602/0330.html because else... our customers who used Outlook (with any version!!!, even 2010!!!) and pop3 mail retrieval protocol and the option of left message copy on the server, where constantly downloading the same messages one time and another (and always they checked for new mail in this MUA... and obviously you know... our customer's annoyance). After applying this patch, although the first problem has been corrected, (the Outlook and UIDL one...) I have observed (and reproduced) that sync_client's forked proccess gets stuck with some mailboxes when SEEN actions that had to move big strings like this one : cyr_dbtool /expert/correo/imap/domain/e/egoitz.com/user/e/egoitz.seen skiplist show 04409b4d4f77894d 1 1333240179 13393 1333240678 11,25,57,63,88,96:97,104,120,130,147,152,158:160,198,204,218,256,263,273,333,335,355,382:383,420,441,458,467,509,514,530,545,548,594,601,616,641,661,665:666,681,703,743,812,819,824,838,847,859,865,878,889,891,894,899,934,953,984,997,1002,1009,1024,1033,1068,1070,1123,1126,1165,1170,1175:1176,1179,1195,1197,1211,1221,1230,1261,1263,1275,1282,1299,1314,1334,1345,1364,1377,1417,1419,1421,1439,1443,1451,1454,1462,1476,1478,1515,1526,1529,1540,1564:1566,1573,1593,1608,1626,1628,1674,1697,1702,1713,1719,1736,1738,1748,1769,1775,1781,1830,1834,1842,1865,1870,1888,1910,1923,1930,1932,1935,1940,1973:1974,2005,2009,2011,2027,2044,2069,2079,2095,2101:2102,2119,2122,2134,2137,2141,2143,2154,2209,2223,2247,2267,2271,2287,2313,2331,2333:2334,2336,2338,2356,2370,2387,2431,2451,2478,2493,2517,2520,2550,2556,2572,2575,2594,2596,2600,2607,2658:2659,2708,2715,2732,2744,2766,2778,2817,2830,2885,2889,2904,2911,2917,2920,2930,2940,2955,2962,2970:2971,2985,3011,3031,3039:3040,3061,3091,3096,3147,31 54,3164, 3171,3180,3183,3191:3192,3199,3219,3221,3225,3227,3230,3235,3254,3264,3273,3280,3304,3343,3361,3371,3375,3406,3414,3419,3425,3445,3463,3489,3492,3499,3525,3556,3564,3604,3636,3643,3665,3667,3670,3691:3692,3747,3797,3801,3803,3811,3852,3872,3883,3886,3907,3930,3993,4020,4036,4043,4105,4113,4142,4149,4159,4172,4187,4218,4220,4257,4309,4363,4365,4369,4371,4393:4394,4400,4434,4463,4481,4515,4551,4554,4581,4585,4591,4600,4641,4663,4710,4713,4721,4767,4792,4818,4872,4898,4928,4961,4977,4979:4981,4983,5009,5014,5037,5064,5076,5105,5156,5165,5177,5193,5208,5241,5261,5275,5281,5296,5298,5311,5313,5321,5328,5334,5343,5363,5392,5395,5401,5404,5408,5427,5440,5453,5466,5483,5520,5527,5537,5549,5597,5603,5608,5613,5652,5683,5688,5692,5719,5730,5747,5753,5764,5804,5845,5848,5860,5880,5883,5887,5910,5919:5920,5937,5950,5963,5974,5980,6014,6017,6032,6043,6052,6054,6070,6143,6180,6194,6273,6307,6342,6378,6384,6389,6407,6418,6421,6435,6443,6452,6480,6488,6534,6544,6556,6566,6576,6588,6603,6616, 6691,673 3,6736,6749,6772,6820,6844,6860,6864,6878,6907,6913,6921,6932,6977,6988,6990,6996,7014,7030,7034,7042,7052,7084,7087,7095,7142,7151,7157,7162,7176:7177,7187,7194,7199,7215,7247,7275,7282,7331,7340:7341,7346,7349,7376,7383:7384,7403,7425,7479,7566,7571,7603,7611,7623,7648,7688:7689,7728,7758,7766,7795,7806,7815,7819,7851,7854,7863,7887,7915,7919,7929:7930,7932,7941,7981,7985,8147,8200,8257,8282,8287,8304,8309,8317,8321,8324,8326,8328,8330,8335,8359,8366:8367,8372,8432,8455,8460,8476,8499,8504,8513,8519,8531,8542,8567,8569,8575,8647,8660:8661,8669,8687:8688,8724,8750,8754,8773,8778,8792,8816,8834,8838,8876,8912,8927,8934,8937:8938,8969,8980:8981,9005,9008,9018,9029,9035:9036,9040,9044,9052,9066,9069,9076:9077,9084,9087:9088,9110,9131,9143,9152,9181,9191,9200,9207,9233,9255,9317,9340,9350,9359,9375,9402,9405,9412,9416:9417,9420:9421,9427,9433,9441,9445,9448,9451,9466,9473,9478,9505,9532,9569,9572,9598,9600,9609,9636,9645,9657,9671,9690,9702,9709,9711:9712,9714,9717,9729,9735,973 7,9740:9 741,9750,9752,9755,9776,9782,9787,9799:9800,9817,9825,9833,9836,9889,9894:9895,9901,9903,9907:9908,9916,9919:9920,9923,9932,9938,9957,9972,1,10027,10062,10065,10095,10109,10147,10159,10183,10186,10193,10239,10307,10347,10374,10423,10426,10434,10437,10479:10480,10495,10502,10513,10515,10523:10524,10538,10552,10566,10574,10595,10611,10615,10620,10624,10647:10648,10650,10660,10672,10674,10683:10684,10704,10715,10757:10758,10780,10784,10786,10788,10826,10830,10841,10863,10865,10868,10873,10884,10892,10905,10915,10927,10953:10954,10962,10975,11027,11042,11044,11053,11056,11061,11076,11103,11169,11196,11205,11218,11285,11295,11315,11317,11331,11333:11334,11338,11351,11354,11361,11377:11378,11381,11405,11407,11412,11414,11440,11452,11484,11486,11489,11493,11498,11541,11552,11562,11579,11601,11608,11610,11618,11657,11684,11688:11689,11697,11713,11717,11730,11739,11750,11754,11775,11788,11794,11840,11862,11864,11869,11871:11872,11901:11902,11922,1
