Re: [Dovecot] Modifying the underlying maildir externally (webmail, replication)
Timo Sirainen wrote: On 20.1.2010, at 22.21, Attila Nagy wrote: After running through http://wiki.dovecot.org/IndexFiles I'm not sure how well would Dovecot work with other programs modifying the maildirs (adding, deleting, moving messages, folders etc). The Main index section says The index file is synchronized against mailbox only if the syncing information changes., where syncing information consists or cur and new directories' timestamps. Does that mean I am safe there? Yes. The worst that can happen is that Dovecot doesn't see external changes for 2 seconds. And that's only if your filesystem doesn't support sub-second timestamps. Are the above right, and can Dovecot use its indexes and caches safely with others using the same maildirs? Yes. I've only recently added maildir_very_dirty_syncs=yes that improves performance but makes it work less safely when other programs modify the maildir. Although there is kind of a potential problem if other programs modify the maildir without locking. http://wiki.dovecot.org/MailboxFormat/Maildir#Locking but that isn't unique to Dovecot. That would cause problems with all programs accessing maildir. Dovecot just logs an error about it, instead of silently giving broken information to IMAP clients. We have the exact same configuration, and we had similar concerns. I'm happy to say that we (so far) have been pleasantly surprised by how well Dovecot handles this situation and keeps its index files in synch while other 3rd parties (web, etc.) are changing the Maildirs. It seems very reliable, and we haven't seen any problems. Tony
Re: [Dovecot] Modifying the underlying maildir externally (webmail, replication)
Tony Rutherford wrote: Timo Sirainen wrote: On 20.1.2010, at 22.21, Attila Nagy wrote: After running through http://wiki.dovecot.org/IndexFiles I'm not sure how well would Dovecot work with other programs modifying the maildirs (adding, deleting, moving messages, folders etc). The Main index section says The index file is synchronized against mailbox only if the syncing information changes., where syncing information consists or cur and new directories' timestamps. Does that mean I am safe there? Yes. The worst that can happen is that Dovecot doesn't see external changes for 2 seconds. And that's only if your filesystem doesn't support sub-second timestamps. Are the above right, and can Dovecot use its indexes and caches safely with others using the same maildirs? Yes. I've only recently added maildir_very_dirty_syncs=yes that improves performance but makes it work less safely when other programs modify the maildir. Although there is kind of a potential problem if other programs modify the maildir without locking. http://wiki.dovecot.org/MailboxFormat/Maildir#Locking but that isn't unique to Dovecot. That would cause problems with all programs accessing maildir. Dovecot just logs an error about it, instead of silently giving broken information to IMAP clients. We have the exact same configuration, and we had similar concerns. I'm happy to say that we (so far) have been pleasantly surprised by how well Dovecot handles this situation and keeps its index files in synch while other 3rd parties (web, etc.) are changing the Maildirs. It seems very reliable, and we haven't seen any problems. Great to hear that, thanks for sharing!
[Dovecot] Modifying the underlying maildir externally (webmail, replication)
Hello, I have a setup where there are multiple maildir users, one of them being the pop/imap server itself, the others are for example a maildir capable webmail and message replication. I would like to evaluate Dovecot, but I wonder how would its binary indexes and logs fit into this picture. After running through http://wiki.dovecot.org/IndexFiles I'm not sure how well would Dovecot work with other programs modifying the maildirs (adding, deleting, moving messages, folders etc). The Main index section says The index file is synchronized against mailbox only if the syncing information changes., where syncing information consists or cur and new directories' timestamps. Does that mean I am safe there? The cache file is hopefully just a cache, so it won't contain information from messages which are inserted or moved by an external program, and I assume Dovecot fetches the message lists and other information from the main index, which seems to be OK. The transaction log is for the main index, so if the latter is OK, the former should be OK too. http://wiki.dovecot.org/MailboxFormat/Maildir talks about MUAs and there nothing scary can be found, except for some temporary conditions, where the changes won't propagate to Dovecot in real time, but it's OK. Are the above right, and can Dovecot use its indexes and caches safely with others using the same maildirs? Thanks,
Re: [Dovecot] Modifying the underlying maildir externally (webmail, replication)
On 20.1.2010, at 22.21, Attila Nagy wrote: After running through http://wiki.dovecot.org/IndexFiles I'm not sure how well would Dovecot work with other programs modifying the maildirs (adding, deleting, moving messages, folders etc). The Main index section says The index file is synchronized against mailbox only if the syncing information changes., where syncing information consists or cur and new directories' timestamps. Does that mean I am safe there? Yes. The worst that can happen is that Dovecot doesn't see external changes for 2 seconds. And that's only if your filesystem doesn't support sub-second timestamps. Are the above right, and can Dovecot use its indexes and caches safely with others using the same maildirs? Yes. I've only recently added maildir_very_dirty_syncs=yes that improves performance but makes it work less safely when other programs modify the maildir. Although there is kind of a potential problem if other programs modify the maildir without locking. http://wiki.dovecot.org/MailboxFormat/Maildir#Locking but that isn't unique to Dovecot. That would cause problems with all programs accessing maildir. Dovecot just logs an error about it, instead of silently giving broken information to IMAP clients.
