[Dovecot] How to propelry restore a Maildir

[Timo Sirainen]

On Tue, 2008-09-09 at 14:16 +0200, Thomas Hummel wrote:
> Assuming someone has got a foobar/[cur|new|tmp] maildir, loses for some reason
> its content and that some new mail (seen and/or unseen) comes into that mailbox
> inbetween (that is before the restore procedure takes place, thus creating the
> need to merge restored messages and new ones).

Safest would be to create "restored mails" mailbox and put everything
there and let the user figure out how to merge things. Might be annoying
enough to merge them so that they'll learn not to make mistakes. :)

> I'd like to check the following (I don't use deliver but procmail) :
> 
>   1. the messages filenames are unique in time (meaning that a new message
>      cannot be assigned a name already existing in the backup (the name of an old
>      message), at least for the same mailbox instance : if that's not the case : how
>      can we merge safely ?

I'm not really sure what you're asking. The file names are unique and
from that point you should have no problems just keeping them. But
Dovecot doesn't really like if messages get "unexpunged", so if it
notices that (due to keeping old records in dovecot-uidlist) it'll log
some warnings and give the messages new UIDs.

Safest would be to rename the files. Maybe just place an extra letter
somewhere in the base file name.

>   2. what naming scheme is used (the left part of the name, before the :2,) ?

You shouldn't need to care.

>        I've got something like :
> 
>        1215166123.52887_0.host.dom.ain:2,[...]
> 
>        what are the 1215166123, the 52887 and 0 ?

UNIX timestamp (seconds since 1970), PID and delivery counter. But none
of that should matter to you. The file name just has to be unique, it
doesn't matter what it contains.

>   3. what can we deduce from the last modified date of the file as seen in ls -l ?
> 
>       . when in new/, is it the same as the one in the Received: header or is it when in tmp/ ?
> 
>       . when in cur/, is it the date the client "saw" the message ? What would
>         "saw" mean in that case ?

The file's mtime is the same as its IMAP INTERNALDATE, which usually
means the time when the message was delivered (as by time() call, not by
looking at any headers) or if the message was saved via IMAP APPEND
command the timestamp could have also been given as a parameter. In any
case it must never change.

>   4. should the dovecot-uidlist and dovecot-keywords be updated after the
>      restore or is it better to let dovecot rearrange them itself ?
> 
>   5. same question for the index and cache files ?

dovecot-keywords could be a problem if the restored mail used keywords,
although it currently isn't a problem since keywords never get removed
so the existing dovecot-keywords file produces correct results. That
might change some day though.

As for other files, don't worry about them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20080909/b0858bfe/attachment.bin