Cyrus caches seen state in memory for a time before flushing it to disk. Generally this works quite well; I use Outlook Express and don't seem to have this problem, but perhaps I just don't do this exact sequence of clicks.
It's possible to force Cyrus to synchronize seen state more quickly with the comparable loss of performance/scalability. Larry Date: Fri, 30 Nov 2001 01:31:37 +0200 From: Heiki Kask <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] > When Cyrus-IMAP writes the seen state, it first makes a copy of cyrus.seen > to cyrus.seen.new(?). This allows other IMAP connections to read the seen > state from cyrus.seen, while the first connection is updating > cyrus.seen.new(?). When it finishes it moves the file to cyrus.seen. I see a contradiction here: Cyrus IMAP server is designed to support multiple connections but it does not work with a client that actually uses them. > one file (i.e. unix mbox format). This requires the UW-IMAP server to lock > the file when it is writing to it, which prevents other connections from > reading the file, until the lock is removed. Is it possible to force Cyrus IMAP server to use some kind of locking mechanism? For some unknown reason most users are running OE as a IMAP client and only way to solve their problems is to do something at the server side. I haven't familiar (yet :)) with internals of the Cyrus IMAP server design, so could somebody explain the background of the multiple connection support? This seems to be handy only for situations when same user is accessing imap folders using different clients. BTW, Thanks for your OE hints! heiki
