*** Mark Crispin ([EMAIL PROTECTED]) wrote today: :) 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.
Hi Mark, One question, though. If your hunch is correct, I see that LockFileEx is only implemented on Windows NT, 2000 and XP, so how does this patch work in Windows 98? I have no way of testing this now, but if someone has tested/can test this change in Windows 9X, I would be grateful for a report. I am particularly interested in seeing how this code works when one attempts to save a message to the same folder that it belongs, and how it works with mbx style folders. It is my own personal belief that Mark is right, and Cygwin c-client should use the windows code directly, instead of the unix code. Maybe we could try to do this instead? What do you think Abraham? Eduardo http://www.math.washington.edu/~chappa/pine/
