[dovecot] Re: [bincimap] Re: Re: bincimap

Andreas Aardal Hanssen dovecot at andreas.hanssen.name
Mon Feb 17 23:31:28 EET 2003


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.

>> >> 1) 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




More information about the dovecot mailing list