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=nnnn) 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.
