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) :
- 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.
- 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.
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.
should the dovecot-uidlist and dovecot-keywords be updated after the restore or is it better to let dovecot rearrange them itself ?
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.