On Mon, 14 Jun 2004, Seth LaForge wrote: >Is this a known problem? Is there a fix? If not, should I look into it >further?
Hi there, Seth. Short answer: It's not a bug, but it'll be faster in 1.3. Here's the long answer :-). The APPEND command writes only one message, and after the command has completed, if you are appending to the same mailbox that is currently selected (INBOX, fex), the new message status and count "SHOULD" be reported to the client. In particular, several clients fall out of sync unless the message they just added to INBOX isn't there when they check immediately afterwards, which is perfectly understandable. So in practise, this SHOULD (that's RFC terminology) is actually a MUST. So after an APPEND, Binc has to scan the mailbox for changes, which takes longer time with larger mailboxes. But that's only half the story, because a scan is usually so fast that you won't notice it. The problem is that the mailbox cache file needs to be written to also. The reason for this is that once the appending client has seen the message, it must assign a UID to it. In order to keep the UID delegation in sync with other concurrent clients, the UID must be stored in the cache file. So every time you APPEND a message to a mailbox your client has selected (which is almost always the case), a big file is created, synced and renamed. The good news is that in 1.3, we'll add the MULTIAPPEND extension (rfc3502.txt). This allows clients to copy several messages in one go, and Binc will then delegate several UIDs in one go, and the cache file will only be written to once for the entire copy operation. Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
