On Jul 18, 2008, at 7:20 PM, Karl Rudnick wrote:
On Fri, 2008-07-18 at 08:52 -0700, Timo Sirainen wrote:
Why does it matter where the timestamp lives? No matter how it was stored, you would have had the exact same problem because your client told Dovecot to use the current timestamp when saving the messages.
And why would keeping the INTERNALDATE in mtime be bad? It only changes if you write to the file. And existing mails must not be modified or you'll get other problems as well.
Actually, it wasn't the client (Outlook) that told Dovecot. I rarely save to my IMAP server from Outlook - only Thunderbird and
Evolution. I think it was a result of my original migration from mbox (uw-imap) to Maildir (uw-imap). I did this by having both IMAP servers (uw and dovecot) accounts alive simultaneously in evolution and let evolution copy from the uw-account to the dovecot-imap account. It could be evolution's fault, but I thought it was doing an IMAP4 copy, in which case the INTERNALDATE should have been preserved according to the
spec, but maybe evolution was just doing its own thing.
You had two servers. There's no trans-server COPY command, so the
client has to fetch the messages from one server and save the messages
to another using APPEND command, which takes a parameter to specify
the INTERNALDATE.
So, before the migration, there was not even the concept of a timestamp on the uw- imap store for each mail.
With mboxes it's stored in the From-line for each message.
Unfortunately, dates can change unexpectedly - not just when you
modify the file, as I move data around between machines as they become
obsolete and the wrong settings in the move can obliterate those mtimes - we humans do make mistakes. Nevertheless, I am happy with my current situation and at least understand what's going on.
Perhaps if you're not careful when copying. :) Anyway there isn't
really any other good place to store the INTERNALDATE than mtime.
Perhaps the timestamp in file name could be used, although maildir
filenames aren't required to start with the timestamp so it should
fallback to mtime then anyway.