MDOSEQ per Mailbox setting

Bron Gondwana brong at fastmail.fm
Mon Jul 8 21:45:04 EDT 2013


On Tue, Jul 9, 2013, at 12:53 AM, lst_hoe02 at 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
  brong at fastmail.fm


More information about the Info-cyrus mailing list