On 17 Feb 2003, Timo Sirainen wrote:
On Mon, 2003-02-17 at 22:07, Andreas Aardal Hanssen wrote:
It seems the qmail community disagrees with you here - I followed the discussion on the qmail mailing list. Do you have URL or something? I didn't find it.
Starts here:
http://marc.theaimsgroup.com/?l=qmail&m=104250383122015&w=2
Sam of Courier-IMAP claimed that OpenBSD's random pid assignment broke qmail and Courier-IMAP. It certainly broke Courier-IMAP.
- use link and unlink, not rename ..and if it crashes (or loses NFS link) between those calls, you'll suddenly see two mails. I prefer atomic operations. Well, then Dovecot has to have a way to communicate this to the sysadmin as an error condition. It's indefinitely better than deleting innocent (blog) users' emails. Reporting lost NFS link is possible, but what if the whole system crashes in the middle?
Then you have either one A link, two links A and B, or one link B. If you have A and B, the Maildir clients should detect this and report it.
All messages delivered to new/ in the same second will get a new middle-part name, sometimes with a _0, _1 ... _n next to the pid. When you move the messages from new/ to cur/ after one second, all new messages delivered to new/ will have a different time part. No collisions. But if you move the messages _before_ one second has lapsed, then a message in cur/ may be overwritten when you either Waiting just has several annoying problems. Either you really wait for one second (ugh), ignore the file (complicates or breaks some new mail checks) or handle it just as if it were in cur/ already (complicates again, you'd have to check if the missing file was actually in new/).
Yes! :-) Waiting one second is quiet intolerable. "Ignoring" the message until it's one second old is the only way that I've found that works. That means that you need to make some precautions with APPEND to currently selected mailbox, but I'm not sure how this works in Dovecot. :-/
Using link avoids the loss of emails, and allows the sysadmin to clean up the server's buggy behavior. rename means bye-bye. When moving from tmp/ to new/, I agree that I should have used link() (fixed in CVS) since there's no harm if the unlink() in tmp didn't occur. Moving from new/ to cur/ or renaming within cur/ is more tricky though. MUAs could see both of the mails at the same time which could lead to weird problems.
Yes - if both mails are present, the client needs to 1) do something smart or 2) ignore the problem and let the sysadmin do something smart.
I don't think you should rely on checking timestamps in any case. What if the maildir is accessed via NFS and some other computer with different time created the file? Maildir relies on timestamps - like it or not. Only system-wide timestamps since the filename contains hostname part. Nothing should break by itself if two systems have completely different times.
True.. but I wish there was a better mailbox storage format out there without little buggers like this messing up the simple design.
Andy
-- Andreas Aardal Hanssen http://www.andreas.hanssen.name/gpg