> On Tue, 15 Mar 2005, Philip Hazel wrote:
>
> > On Tue, 15 Mar 2005, [gb2312] ���� wrote:
> >
> > The MBX locking rules are specifically defined by the folks who invented
> > the MBX mailbox format. The whole idea is to enable the use of shared
> > mailboxes.
Indeed... but what does that mean, exactly? Let's have a look.
> > I have a document entitled
> >
> > UNIX Advisory File Locking Implications on c-client
> > Mark Crispin, 28 November 1995
The following is from that document:
This form of locking makes fewer presumptions, but it still is
guilty of presumptions (2) and (4) above. Presumption (2)
limits the ability to have processes sharing a resource in a
non-conflicting fashion (e.g. reading from a file). Presumption
(4) leads to deadlocks should the process crash while it has a
resource locked.
We seem to be talking about sharing mailbox files in RO mode.
On Wed, Mar 16, 2005 at 10:15:31AM +0800, sparrow wrote:
> I downloaded a copy of uw-imap source code and read through the section of
> mbx.
> I found that mbx_open (open a mailbox)and mbx_append (append message to a
> mailbox) are implemented differently in locking the mailbox.
> mbx_open get a exclusive lock on the temp file and a shared lock on the
> mailbox, then release the exclusive lock on the temp file.
> But mbx_append only acquire a exclusive lock on the temp file after
> opengin the mailbox file. There is no code acquiring a shared lock on the
> mailbox.
I think a careful reading of the cited document supports this reading
of the code. The point of the mbx format, IIRC, is to allow multiple
clients to concurrently READ the same file. However, when write
access is required (i.e. to append a message to a file), which I'm
making a baseless assumption that is the only mode in which exim will
operate on the file, only the exclusive lock is needed. Exim has no
need of a shared lock, because it (AFAIK) has no need to hold the file
open for reading... Isn't that the case?
> I'm wondering if the exim implements mbx open according to mbx_open of
> uw-imap, or some documented specification says it must be implemented this
> way. If a specification exists, I really wish to have a read. If no, I
> think exim sould do as mbx_append when delivery mail using mbx format.
Based only on my understanding of what Exim is doing (that being
delivering mail), the reading of the cited document, and discussion
here, without reviewing the code for either program, it seems to me
that Exim does not implement locking consistently with c-client.
There seems to be no point whatever to the shared lock...
I've reviewed this document before in regard to another program, and I
think a number of things are worth pointing out:
1. It was written 10 years ago. Much has changed in the Unix world by
now. For example:
- the bugs in most statd's and lockd's have long since been worked
out.
- fcntl() locking is part of the POSIX standard, and is now
available on almost any reasonably modern Unix variant. It's true
that legacy systems still won't have it, but IMNSHO sites which
refuse to migrate from guaranteed broken, positively unfixable
systems deserve whatever they get...
- It's reasonable to think that the several other bugs Crispin
mentions are either fixed by now or caused by site-specific
misconfigurations, and in either case not the purview of the
application developer.
2. All that said, my understanding is that it is STILL the case that,
in a heterogenious environment, NO LOCKING METHOD WORKS RELIABLY
OVER NFS. If all of your systems are homogenous and have known
working statd and lockd implementations, locking on NFS is OK, but
ONLY IF THE RIGHT METHOD IS USED ON THAT PLATFORM. The normal way
to do this is to use the link(2) system call (see the Linux open(2)
man page, in the explanation of O_EXCL, or see W. Richard Stevens,
_Advanced Programming in the Unix Environment_, for the details).
A friend of mine who is a kernel developer, and former maintainer
of Linux NFS utils, told me that the method mentioned in that man
page also suffers from a race condition on NFS, and is not
reliable. After nfs-utils was fixed in version 0.3.5 or some such,
the only reliable method of locking over NFS on Linux has been
fcntl() locking, so I am told. However, this information is itself
3 years old, and may or may not still be accurate.
The upshot of all that, I think, is that developers should stick to
fcntl() locking from heretofor (and abandon platforms that still don't
have it, if there are any), and assume that locking simply will not
work over NFS, and warn users away from putting contentious files on
NFS-mounted filesystems. To be specific, NFS-mounted mail spools are
dangerous, especially in heterogenious environments.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
