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