On Tue, Jul 9, 2013, at 12:53 AM, lst_ho...@kwsoft.de wrote: > Ok, so i can tell the wiki maintainer that the information should > mention that this only applies to Cyrus <2.4.
Correct. Maybe I should have left the annotation in, just forced on! > One more related question: > > I have got this warning in the logfile which also pointing to MODSEQ > problems, no? > > "Jul 8 16:40:19 mailer cyrus/imap[32155]: inefficient qresync (1472 > > 1) user.xxxxxx" Why on earth would you send a MODSEQ of 1 and ask for all changes since then? That's crazy. Seems like a bogus client. > From what i have read here > http://git.kolabsys.com/cyrus-imapd.git/commit/?id=e3f72960b1349f1dffea0160d7bc7478f429cc54 > it looks like syncronisation based on MODSEQ does not work as expected for > this client? Any idea where to debug or what the actual problem could be. The > warning appears on any sync attempt as far as i can > tell. Well - it works fine. The client is just being stupid. What a client is SUPPOSED to do is make an initial request for the data it wants, and then note the HIGHESTMODSEQ in the response. Next time it connects, it can "resync" by asking for changes since the last value it saw. But asking for changes since '1' - obviously that's everything. The reason we log that it's "inefficient" is that we don't have full information for every deleted message any more, so we have to assume every gap in the UID listing is a deleted message. It's still fine - the response from Cyrus is correct, and the client will work correctly too. I guess maybe I should make that message not be logged if the request is "since modseq == 1", since clients do that. Then it will only happen if you reconnect after a week and the expunged messages have been expired. Regards, Bron. -- Bron Gondwana br...@fastmail.fm ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
