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

[Timo Sirainen]

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.

> >> 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?

> >It only has requirement that the file name is unique. There's other ways
> >to do that than time(NULL). http://cr.yp.to/proto/maildir.html lists
> >some.
> 
> "A unique name has three pieces, separated by dots. On the left is the 
> result of time() or the second counter from gettimeofday().

Yeah, I should actually read things instead of skipping to interesting
part :)

> 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/).

> 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.

> >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.