On Tue, 21 Oct 2003, Abe Backus wrote: > 1) the flock simulator for cygwin in flockcyg.c has the same limitations as > the flock simulator for NT, so the code should only lock on one byte in the > file. The person that brought this to my attention would prefer that the > code lock the last possible byte in the file.
I have accepted this change, but to lock the first byte of the file. I do not believe that it is safe to lock a non-existant byte of a file, since we have no way of knowing if future changes to Cygwin or Windows would break that. Arguably, the real bug is in Cygwin's implementation of fcntl() locks. Cygwin is evidentally calling LockFileEx() on Windows directly, without attempting to implement the correct fcntl() semantics. In one case, this is a good thing -- it doesn't implement the fcntl() design flaw that requires all that flocksim master/slave hackery -- but in this case it is not a good thing. I'm not convinced that Cygwin should use the UNIX version of c-client instead of the native Windows version. > 2) CRAM-MD5 wasn't working on cygwin I don't see how it can work either. Those logon/impersonate calls are necessary to get access to the user files. Removing those calls in the CRAM-MD5 case has the effect of leaving the IMAP server running as SYSTEM, which IMHO is not a good thing. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
