On Mon, Feb 8, 2010 at 6:18 AM, Erik Faye-Lund <kusmabite@xxxxxxxxxxxxxx> wrote: > On Sat, Feb 6, 2010 at 11:18 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: >> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote: >>> However, I have tracked down a bit of what goes on in the client. >>> There's a call to read_in_full, called from pack-write.c, line 246 >>> that fails in the failure-case, but not in the success-case. This is >>> where the client expects "pack\tSHA-1" or "keep\tSHA-1". There "fatal: >>> early EOF"-messages seems to originate from index-pack.c, line 197. >>> This is the first line of code in parse_pack_header(), it's also >>> AFAICT the first call-site for any read(0, <...>) (though fill()). >> >> This looks like upload-pack died without sending enough to fill a pack header. >> >> Try merging this branch: >> >> git://repo.or.cz/git/mingw/j6t.git async-in-thread >> >> It contains your changes to start_async plus a refinement of die() when it is >> called from the async procedure (it passes t5530, for example). It is also >> converted to pthreads, and therefore also works on Unix. The new >> implementation of start_async is more careful about the file handles, though >> not so much on Windows. >> >> If there's no change for you, then you could look into implementing >> fcntl(F_GETFD/SETFD, FD_CLOEXEC), which are currently ignored, on top of this >> branch, using Get/SetHandleInformation(). >> > > Thanks a lot. I tried merging it, but the issue still pops up. I also > tried to implement fcntl(F_GETFD/SETFD, FD_CLOEXEC), still no dice. > I'm not entirely sure if I did it correctly, though. I have no idea if it's related, but a similar thing seems to happen with git under cygwin-1.7.1. http://article.gmane.org/gmane.os.cygwin/114032 This is when cloning/fetching over ssh. I've not personally seen the problem, but I compile git from source. Coworkers who are using the cygwin-1.7.1 provided git see the problem consistently. j. -- 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