On Tue, 1 Apr 2003, Andreas Aardal Hanssen wrote: > On Mon, 31 Mar 2003, Charlie Brady wrote: > > >each message already has a good value for "internal date" - it's the first > >component of the maildir message file name. All you need to do is to > >preserve that number when copying messages to a different maildir. > >This is something that I fixed in the maildir patches for UW-IMAP (by > >re-enabling code which had been commented out), and my Outlook users were > >much happier. > > I think your patch may be seriously broken, and there was a good reason > why the code was commented out.
As I say, the users were much happier. > >Just because Courier and dovecot are wrong doesn't mean that Binc should > >be. > > They all do it the same way, because there is (I should post this on the > FAQ) _no way_ to deliver a message to a Maildir without using time(NULL) > as the base (first part) of the message. If you set this portion of the > message, as you say, to a predefined value that is typically << time(NULL) > then messages will disappear because you are not guaranteed that all > messages in cur/ will have different bases. > > Dovecot started doing this after I posted the exact recipe for Dovecot to > lose a bunch of messages. You can look that up in the archives. Timo said > something about "come on, what's the chance of that happening" and refused > to fix his Maildir code, but he eventually caved in when I showed him how > easily this race can be reproduced in real time. > > Saving to tmp, then linking to new/ with time(NULL) is a Maildir > requirement, not an option, and Dovecot and Courier-IMAP and Binc IMAP are > not doing it wrong. Perhaps they should all remove their claims of RFC2060 compliance in that case. Only joking - it says "SHOULD", not "MUST". The race condition you referred to on the dovecot mailing list concerned delivery of new messages at the same time that a client (e.g. imap server) was moving messages from new/ to cur/. This isn't the situation with old messages which you intend to move around. Their basenames have already been disambiguated at delivery time, at least for the common simple case of a single inbox per user, and in the case of multiple inboxes and an OS which doesn't recycle PIDs within one second. I do not agree with you that using time(NULL) is a Maildir requirement. The only essential requirement (in bold from http://cr.yp.to/proto/maildir.html) is "every delivery to this maildir must have its own unique name". I'm sure that you can meet that requirement, without adverse results. OTOH, if you do not satisfy the RFC2060 recommendations wrt internaldate, then you will have unhappy users. Perhaps there is another way that internaldate can be preserved when messages are copied or appended. Could we not adjust ctime or mtime and use that? -- Charlie
