On Wed, Apr 04, 2001 at 10:42:54AM +0100, Ray Miller wrote:
> Not quite. There are a couple of differences between the exim and
> c-client implementations of mbx locking which have potentially
> disasterous implications. c-client uses the flock() system call for
> file-locking, whereas exim uses flock(). Ignoring the different
[I assume one of those is supposed to be fcntl() ?]
> semantics of the two system calls, this works on some systems
> (e.g. Solaris, where flock() is implemented via fcntl()), but on other
> operating systems (e.g. Linux, where flock() and fcntl() are
> implemented as independent system calls) it is possible for one
> process to lock a file using flock() and another process to lock the
> same file at the same time using fcntl(). There's also a difference in
Erm, so ? Again, this is implementation vs. implementation. If Phil or
anyone working on code for exim cannot rely on an independent model
for the mbx format but instead has to keep up to date with the moving
target that is c-client, then the problem is clear.
A specification for mbx locking would talk about the types of locks,
not the OS and language specific details. Yes, I am aware that this
is a wish for nirvana and that C is a system programming language
that is usually singled out for exactly this kind of thing, but how
do we then go and implement MBX access in perl / python / Java etc. ?
Before anyone starts, I am aware of the existence of subtlties of
locking and all the interfaces - but when I need to know, I read
Steven's and the OS specific docs - I do NOT try to remember
everything, so my comments are deliberately vague.
> the logic used when unlinking the lockfile from /tmp - I haven't
> managed to convince myself that a process will never end up with a
> lock on a file that's been unlinked by another process.
I have not looked at the code to either in over a year. If people are
having real problems I would be happy to find some time and put on my
effluent proof suit to dive into c-client again.
> But we're talking about out-of-the-box exim and c-client, not a
> locally butchered version. I'd caution against using exim's native MBX
> delivery in parallel with c-client applications. I'd almost go as far
> as suggesting the removal of mbx support from exim because it is not,
> in general, compatible with the c-client routines.
OK, that was a red herring. My local version is / was for performance,
reliability and maintainability. The original UW-IMAP (4.7 something -
the author refused to stick to version numbers) worked fine within the
bounds of all the other performance problems.
> I'd be interested to hear about your local solution. We use an exim
> transport that invokes tmail to do local delivery but would prefer to
> use exim's native support - if we were convinced that it was safe.
We are now moving to maildir (which is partly where this thread
started) since we need a system that can be built on a many-to-many
server architecture. NFS is a pig, but can be useful if dealt with
carefully.
rgds,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
