Re: Mutt Next Generation
Hello,
I want to give an overview what can be go wrong when using maildir
together with header cache and what can't.
When mutt opens a maildir it opens the header cache database. This
header cache database has to be locked to ensure that only one instance
can write at the same time (multiple readers are possible with gdbm, but
not with db4). If mutt can't open the header cache for writing (it falls
back on reading in the gdbm case) and if it can't be opned for reading
mutt proceeds without header cache.
This lock is aquired in a NFS safe manner. If your NFS server doesn't
support locking, I don't know what happens. But I don't recommend to put
the hcache database on NFS for the following reasons, but I tested it
myself with concurrent access from two differnt machines via NFS.
- You could accidently access the same header cache from
different architectures which would crash mutt for db4 (gdbm
handles that as well).
- Bad performance: Retrieving the database via NFS takes usally
longer than retrieve it from local harddisk or even virtual
memory.
Personally I put my hcache database in /tmp which is tmpfs.
This problems can of course also happen, if you use IMAP header cache.
The following can go wrong when using header cache together with
maildir:
- You use an old and broken procmail to deliver eMails in a
maildir. Older procmails used the ':' in the unique part of
the filename, which is normally used as seperator between
unique part of the maildir filename and flags. In big
mailboxes it comes to collisions which lead to wrong headers
eMails.
- When using mairix for example a symlink of a virtual maildir
could point to nothing. If you disable maildir_header_cache_verify
a broken symlink will not be detected and so will an eMail
indexed, which doesn't exists. If you press 'return' on that
eMail, mutt will raise an error, but continues to work.
Greetings,
Thomas