On Thu, 8 Jul 2004 Mark Crispin Wrote: [About File Locking mboxes over NFS] > If you are lucky, the worst that will happen is that from time to time an > IMAP server will crash with the message "Unexpected changes to mailbox"; > that is, it will detect what happened and kill itself rather than cause > any damage. > > If you are unlucky, the mailbox will be corrupted, messages will be lost, > etc. If you get a message about "mailbox vulnerable" and talking about > 1777 protection, then you are definitely unlucky; and disabling that > message will not remedy matters but rather simply disable the warning of > your misfortune. >
Quoted from July 8: [EMAIL PROTECTED] ""> Again - from what I understood, this issue with flock() over NFS has been > > fixed - besides isn't that what the nfslock daemon is for? > > I hope not! Those lock-over-NFS daemons are for fcntl() locking only, and > THEY DO NOT WORK WORTH A DAMN! It is a *feature* that flock() does not > use those broken daemons. > > > To me this means that the documentation on file locking is relevant to > > us???? Although I don't feel that I fully understand the implications."" > The jist that you should get is that although there is basic compatibility > in locking between all this software, you should use companion software > whenever possible. > > For example: if you use UW imapd for your IMAP server, you should use UW > ipop3d for your POP3 server. If you use Cyrus imapd for your IMAP server, > you should use Cyrus pop3d for your POP3 server. > > If you mix non-companion softare, such as UW imapd and cucipop, you will > have basic compatibility on locking but less compatibility than if you use > companion software. To what extent this may cause problems is uncertain. > It is not a recommended configuration. Thank you Mark for your response in July. Now we are deploying a second server to do just as you reccommended and we are putting all mail services on the same machine and to improve performance we are separating the user space as you suggested. We have chosen however to use UW's imapd with qpopper instead of with ipop3d because of our experience with qpopper outperforming ipop3d by leaps and bounds. Are you aware of this, and has ipop3d's efficiency been improved within the last year or two? Also, is there any more you can say to expound upon when you said "To what extent this may cause problems is uncertain" What kind of things should we be looking for? Mail lost silently? Deadlocks?
