Re: [Dovecot] 1.2.13 QRESYNC crash.
On Mon, 2010-08-23 at 18:04 +0100, Timo Sirainen wrote: On Mon, 2010-08-23 at 17:33 +0100, David Woodhouse wrote: And thanks for not (yet) making it reject the invalid command with the 1:* in it I changed it in v2.0. -- I'll need to come up with a strategy for migrating to the 'correct' command on the client side, given that older versions of dovecot won't accept it. I'll probably make the Evolution client code start off by trying the correct command, and then retry with the bogus '1:*' if that fails. Can't you simply send 1:last uid you've seen? I *might* be able to get away with that, and fetch flags for any newer messages at the same time as I fetch the headers for those messages. I'll check. Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too. 1:4294967295 doesn't really fill me with joy either -- that assumes that a UID is limited to 32 bits unsigned... and that other servers won't fall over when presented with that number. -- dwmw2
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Thu, 2010-08-26 at 14:32 +0100, David Woodhouse wrote: Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too. 1:4294967295 doesn't really fill me with joy either -- that assumes that a UID is limited to 32 bits unsigned... It is, as defined by RFC 3501. and that other servers won't fall over when presented with that number. Well, those servers would also be broken then.. I think servers can typically handle such UID better than clients (many clients use signed 32bit ints). I think there's a good chance it would work fine with all servers that support QRESYNC.
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Thu, 2010-08-26 at 17:02 +0100, Timo Sirainen wrote: On Thu, 2010-08-26 at 14:32 +0100, David Woodhouse wrote: Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too. 1:4294967295 doesn't really fill me with joy either -- that assumes that a UID is limited to 32 bits unsigned... It is, as defined by RFC 3501. and that other servers won't fall over when presented with that number. Well, those servers would also be broken then.. I think servers can typically handle such UID better than clients (many clients use signed 32bit ints). I think there's a good chance it would work fine with all servers that support QRESYNC. OK, I'll do that then. Thanks. -- dwmw2
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Sat, 2010-08-21 at 16:15 +0100, David Woodhouse wrote: A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757))) Dovecot doesn't like that though: A00131 BAD Error in IMAP command SELECT: Invalid QRESYNC parameters Whops. Looks like I read the RFC a bit wrong. Fixed in v2.0 and v1.2 hg now. I guess I should release 1.2.14 then. Could you try that the fix works properly? At least it doesn't give any errors anymore. http://hg.dovecot.org/dovecot-1.2/rev/7e959d397a35
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Mon, 2010-08-23 at 15:40 +0100, Timo Sirainen wrote: Whops. Looks like I read the RFC a bit wrong. Fixed in v2.0 and v1.2 hg now. I guess I should release 1.2.14 then. Could you try that the fix works properly? At least it doesn't give any errors anymore. http://hg.dovecot.org/dovecot-1.2/rev/7e959d397a35 Looks like it's working; thanks. Tested against 1.2.13. And thanks for not (yet) making it reject the invalid command with the 1:* in it -- I'll need to come up with a strategy for migrating to the 'correct' command on the client side, given that older versions of dovecot won't accept it. I'll probably make the Evolution client code start off by trying the correct command, and then retry with the bogus '1:*' if that fails. I don't really want to just 'fix' the client and let people get errors with older versions of Dovecot, even though QRESYNC support is optional. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Mon, 2010-08-23 at 17:33 +0100, David Woodhouse wrote: And thanks for not (yet) making it reject the invalid command with the 1:* in it I changed it in v2.0. -- I'll need to come up with a strategy for migrating to the 'correct' command on the client side, given that older versions of dovecot won't accept it. I'll probably make the Evolution client code start off by trying the correct command, and then retry with the bogus '1:*' if that fails. Can't you simply send 1:last uid you've seen? Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too.
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Thu, 2010-08-19 at 18:37 +0100, Timo Sirainen wrote: On Wed, 2010-08-18 at 22:27 +0100, David Woodhouse wrote: Aug 18 22:07:31 twosheds IMAP(dwmw2): : Panic: file mail-index-transaction.c: line 637 (mail_index_transaction_lookup): assertion failed: (seq = t-first_new_seq seq = t-last_new_seq) A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 1:* (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757))) Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e Hm, looking at RFC5162 again I realise that SELECT command isn't actually valid. The '1:*' for the known-uids is not permitted. From the formal syntax in §6: capability =/ QRESYNC select-param= QRESYNC SP ( uidvalidity SP mod-sequence-value [SP known-uids] [SP seq-match-data] ) ;; conforms to the generic select-param ;; syntax defined in [IMAPABNF] seq-match-data = ( known-sequence-set SP known-uid-set ) uidvalidity = nz-number known-uids = sequence-set ;; sequence of UIDs, * is not allowed known-sequence-set = sequence-set ;; set of message numbers corresponding to ;; the UIDs in known-uid-set, in ascending order. ;; * is not allowed. known-uid-set = sequence-set ;; set of UIDs corresponding to the messages in ;; known-sequence-set, in ascending order. ;; * is not allowed. §3.1 says: If the list of known UIDs was also provided, the server should only report flag changes and expunges for the specified messages. If the client did not provide the list of UIDs, the server acts as if the client has specified 1:maxuid, where maxuid is the mailbox's UIDNEXT value minus 1. So instead of giving the known-uid set '1:*', the client should actually have omitted the optional known-uid parameter completely. It *should* have sent this command: A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757))) Dovecot doesn't like that though: A00131 BAD Error in IMAP command SELECT: Invalid QRESYNC parameters -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Wed, 2010-08-18 at 22:27 +0100, David Woodhouse wrote: Aug 18 22:07:31 twosheds IMAP(dwmw2): : Panic: file mail-index-transaction.c: line 637 (mail_index_transaction_lookup): assertion failed: (seq = t-first_new_seq seq = t-last_new_seq) A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 1:* (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757))) Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Thu, 2010-08-19 at 18:37 +0100, Timo Sirainen wrote: Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e Thanks. Obviously you've been able to test on exactly the same mailbox I'm using, so you'll not be surprised to hear that the patch works fine here too. Do shout if you see anything that could be improved about the client's behaviour, by the way -- this is Evolution's 'imapx' back end. It's including sequence numbers working backwards exponentially from the end of the folder -- so for a folder which had N mails last time we looked at it, we'll include sequences N-9, N-27, N-81, N-243, N-729, etc. in the QRESYNC request. Does that seem reasonable? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation
Re: [Dovecot] 1.2.13 QRESYNC crash.
On Thu, 19 Aug 2010 18:37:16 +0100, Timo Sirainen t...@iki.fi wrote: On Wed, 2010-08-18 at 22:27 +0100, David Woodhouse wrote: Aug 18 22:07:31 twosheds IMAP(dwmw2): : Panic: file mail-index-transaction.c: line 637 (mail_index_transaction_lookup): assertion failed: (seq = t-first_new_seq seq = t-last_new_seq) A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 1:* (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757))) Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e your this fix me its clean up : enjoy
