On Fri, Mar 18, 2005 at 10:58:32AM -0500, Derek Martin wrote:
> I've written e-mail to Mark Crispin asking about the impolementation.
> If/when I receive an answer, I'll forward the results.
Here's Mark's response (with a couple of short comments of mine).
Mark, thanks for your quick response.
On Fri, Mar 18, 2005 at 11:22:41AM -0800, Mark Crispin wrote:
> As it is, I agree and disagree with both sides. Please don't quote me
> unless you quote this response in its entirety.
>
> That old locking paper that I wrote does not specifically deal with mbx
> format, which has a number of semantics that are unique to it. However,
> on the crudest level, the text about tenex and mtx applies.
>
> It is correct that, for appending, the current c-client code only acquires
> the exclusive parse/append lock (on the /tmp file) and does not acquire a
> shared lock on the actual mbx mailbox file. However, this may change in
> the future when the delete/rename code gets restructured.
>
> The bottom line is that there is no harm on UNIX in acquiring a shared
> lock on the mailbox file prior to initiating an append; and in the future
> it may become mandatory.
[Here seems to be the crux of the matter:]
> The problem in mail delivery on Cygwin is due to a bug in Cygwin; it does
> not emulate flock() correctly. Cygwin uses the Windows LockFileEx() to
> implement flock(), even though Windows LockFileEx() is mandatory and UNIX
> flock() is advisory. The UNIX mbx driver *requires* that flock() be
> advisory.
>
> As a workaround, instead of using Cygwin's broken flock(), Exim can use
> the Cygwin version of the flocksim() code in c-client. This code only
> applies the lock on the first byte of the file and goes through the
> fcntl() interface. Make sure that it uses the flockcyg.c version and not
> other versions which are also in c-client.
>
> I recommend this as a far superior path for Exim to take than to remove
> the shared lock.
>
> Now, onto the necessary "cover my posterior"...:
>
> I do NOT support Cygwin in c-client. Cygwin does not implement true UNIX
> semantics; it implements an unpredictable mix of UNIX and Windows
> semantics.
>
> Although a modest amount of effort has been made to get some aspects of
> UNIX c-client to work under Cygwin, there are several known problems that
> will never be fixed. The answer to these problems is: "there's a native
> Windows port of c-client."
>
> Furthermore, c-client under Cygwin does *not* interoperate with native
> Windows c-client. This is a recipe for disaster.
>
> I can't speak for Philip Hazel, but I guess that he may have similar
> sentiments about Exim under Cygwin.
FWIW, I wholeheatedly agree with this sentiment from Mark:
> Personally, I find it bewildering that anyone would want to run something
> as complex as a mailer (such as Exim) under Cygwin, rather than any of the
> following far superior solutions:
> . run a native Windows mailer
> . run true UNIX instead of UNIX
[I think he meant something like, "...instead of UNIX emulation" there]
> . do a true Windows port of Exim
> . use VMware to run true UNIX under Windows
>
> There are limits to what a system call compatibility package (which is
> what Cygwin is) can do for you. Please keep this in mind.
>
> I don't want to sound harsh, but I get very nervous when people start
> talking about software running under Cygwin in starry-eyed terms which
> imply support. Thanks for your understanding.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
