dovecot - Aug 2008 - Purpose of files under .imap

I've got a user with an unusable account. Tbird just sits in a loop 
endlessly logging in over and over when a particular folder is selected.

What files under .imap associated with that folder can be safely deleted? 
What's stored in all of them?

I see all of these:

.customflags
dovecot.index
dovecot.index.cache
dovecot.index.log
.imap.index
.imap.index.data
.imap.index.log
.imap.index.tree

On Aug 6, 2008, at 9:53 PM, Kenneth Porter wrote:
> I've got a user with an unusable account. Tbird just sits in a loop  
> endlessly logging in over and over when a particular folder is  
> selected.
>
> What files under .imap associated with that folder can be safely  
> deleted? What's stored in all of them?
What Dovecot version? What do you see in Dovecot's logs? Instead of  
deleting move the files so that if it's a new bug that I haven't fixed  
I could take a look at the indexes to see if I can get it fixed.
> I see all of these:
>
> .customflags
v0.99-only, delete.
> dovecot.index
> dovecot.index.cache
> dovecot.index.log
All of these are safe to delete.
> .imap.index
> .imap.index.data
> .imap.index.log
> .imap.index.tree
These are v0.99-only, delete.

So I guess you're using mbox? There it's safe to delete everything. If  
you're using maildir you should keep dovecot-uidlist and dovecot- 
keywords.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080806/752596d7/attachment-0002.bin>

On Wednesday, August 06, 2008 10:18 PM -0400 Timo Sirainen <tss at iki.fi>
wrote:
> So I guess you're using mbox? There it's safe to delete everything.
If
> you're using maildir you should keep dovecot-uidlist and
dovecot-keywords.
I'm in the process of getting my head around the least painful path to 
convert everything to maildir, given the headaches mbox is giving me here.

It looks like I can leave mail_location unset, and use a basic namespace to 
force the separator to be the same as for mbox:

namespace private {
   separator = /
   inbox = yes
}

procmail is used as the LDA on CentOS so I then need to change procmailrc 
to direct incoming mail to Maildir, presumably by adding:

MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/

It looks like I can do this on a per-user basis by putting that in a user's 
.procmailrc until I migrate everybody.