On Fri, 2013-02-08 at 13:17 +0100, Paolo Miotto wrote:
> So I set up a test server, copied a true mailbox and changed mail
> location from:
> mail_location = maildir:~/Maildir
> to
> mail_location = maildir:~/Maildir:INDEX=/srv/indexes/%1n/%n
> (all users under the same domain, no need to use %d).
>
> On the IMAP side all seems to work fine, new indexes are created in
> the new location (dovecot.index.log on 1st access, dovecot.index.cache
> on message manipolation).
>
> A test client (evolution) doesn't notice at all, and I have verified
> via a telnet imap session that UIDs don't change.
Your load probably temporarily increases so cache file gets filled.
> But I see that when I move the indexes the IMAP HIGHESTMODSEQ response
> changes and is reset to 1. Can this baffle the clients? On the rfc I
> don't found reference to this status walking backwards.
Hmm. Good question. I remember wondering about using some kind of a
timestamp-based root value. Something like time()*1000 would probably
work quite well, but this of course increases the size of all the modseq
values, which somewhat wastes bandwidth and also makes debugging a bit
more annoying :)
Thunderbird is probably the only widely used client that uses QRESYNC.
You could see if it breaks.
> Need I to verify that all messages have the virtual size (W=) in
> the file name (the mailboxes are from a previous cyrus installation,
> then we switch to dovecot 1.2)?
W=size or S=size aren't required in the filenames. Also if you change
them, make sure to change dovecot-uidlist also or the UIDs change.
> What other test you suggest that checking UIDL on the pop3 side?
POP3 session with UIDL command? :) Anyway POP3 UIDLs are never stored in
index files.
> What happens if the indexes disk disappears (broken or removed from
> bay or all paths down for FC/iscsi)? Can dovecot 1.2 continue with
> INDEX=MEMORY as for a disk full?
There is code to do something like that, but it might not work
perfectly. Especially with v1.2 that is rather old.
