On Tue, 4 May 2010, Timo Sirainen wrote:
This mtime
flushing actually works pretty easily in all modern OSes: just open and
close the file and then stat/fstat.

Yup.  You just said it: "modern OSes"...

I remember an OS which would not update mtime if ANY local agent had the
file open.  So, no matter how many times you did an open/close/stat, you
would get the same out of data data.  That, interacting with NFS attribute
caching, made things quite painful.

Perhaps this is now just a sad memory and no longer needs to be worried
about.

Yeah, I actually also fallback to MD5 of a few specific headers if
X-UID: headers haven't been written to disk yet.

That may work as long as Received: headers are included.

Also, these days, MD5 is not patent encumbered nor is it under any
export restrictions.  That wasn't the case back then...

UW IMAP has no such thing as "X-UID headers haven't been written to disk
yet" for existing messages.  That state only exists with new mail, and the
first thing UW IMAP does is write those X-UID headers.  Safer, but slower.

The annoying thing with Dovecot's mbox optimizations is that they're
pretty complex and I'm sure there are bugs there. Also it's difficult to
sometimes figure out if something is a bug or just a side effect of some
other software modifying the mbox, possibly with incompatible locking
rules, etc..

Yeah, and when I was supporting 80,000 people using that format over NFS I
did not want to take that risk.

So I'm kind of hoping people would stop using mbox. :)

You and me both!  ;)

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to