On Sat, 2007-02-10 at 12:58 +0100, Philip Van Hoof wrote:
Dovecot's IDLE (the EXISTS) responses also take a lot longer on tnytest2 than on tnytest.
That is because with maildir Dovecot can use kernel's dnotify support to know immediately when a new mail arrives. Inotify apparently supports also waiting for file changes, so I think it should work if you configure --with-notify=inotify. I'll have to try this myself too..
- OK [UIDNEXT 1] Predicted next UID a01 OK [READ-WRITE] Select completed. a04 IDLE
- idling
- 1 EXISTS DONE
How did you get those messages into the mailbox? Just wondering why it's not giving RECENT reply.
a04 OK Idle completed. a05 UID FETCH 1:1 (FLAGS UID) a05 OK Fetch completed.
Looks like I can reproduce this. At least with empty mailboxes it seems that Dovecot gives a new UID to a mail that already had it. I'll go and fix this.
However, Dovecot's behavior is perfectly valid from IMAP protocol's point of view. You shouldn't be assuming that the new UID is the same as UIDNEXT. For example another session could have just appended two messages and expunged the first one. In that case you'll see exactly the above behavior from all the IMAP servers.
So you really should be using message sequence numbers instead of UIDs before you're completely certain what the UID is. And even still using sequence numbers is a more "correct" IMAP way to do it, plus it's slightly faster :) I think the UIDs are mostly useful only for some initial local cache syncing when the mailbox is opened.
a06 UID FETCH 1:4 (FLAGS UID)
- 1 FETCH (FLAGS (\Seen) UID 2)
- 2 FETCH (FLAGS (\Seen) UID 3)
- 3 FETCH (FLAGS (\Seen) UID 4) a06 OK Fetch completed.
This is because the fourth message had UID 5 and you exluded it from the fetch.