On Fri, Mar 04, 2011 at 09:16:30AM -0800, Junio C Hamano wrote:
> How prevalent is the problematic cygwin1.dll 1.7.8? Also for how long did
> this bug exist, in other words, if we were to make a table of problematic
> versions, would we have only just a handful entries in it? Also can we at
> runtime find out what version we are running?
>
> The reason I am asking these questions is because I think, assuming that
> this would affect many unsuspecting Cygwin users, the best fix would be to
> add a hook in the compat/ layer that decides if MAX_WRITE_SIZE workaround
> is necessary at runtime, and do something like this:
>
> ssize_t xwrite(int fd, const void *buf, size_t len)
> {
> ssize_t nr;
> static size_t max_write_size = platform_max_write_size();
>
> if (max_write_size && max_write_size < len)
> len = max_write_size;
> ...
> }
How are we doing the runtime test for platform max write?
If I read the original bug report correctly, the problem was that write
would actually write some bytes _and_ return -1, which is terrible. We
can detect "seems to be returning -1 over and over", but we can't handle
a misbehavior like writing and claiming not to have done so.
So I think the test needs to be "is our version of cygwin in the broken
list" and not "let's try a few different writes and see what works".
But it is still not clear to me how many versions have this bug. I think
the next stop is to show the cygwin developers a clear test-case and see
whether it's already fixed, and which versions show the behavior. They
should be able to get that information much more easily than us. I
really don't want to get involved in bisecting bugs in cygwin (according
to cygwin.com, it's kept in CVS. Blech).
Robert, can you try (or have you already tried) submitting a bug report
to Cygwin?
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html