Hi, I've cc:'d the mailing lists and the participants of the earlier discussion to share your findings and to see if someone else may have an explanation for this behaviour, or a solution. The patch in question is c8b296450e5148c576697ea4709072b7855aacd5 and has made it into git versions 1.7.1.1 and 1.7.2 (and up). It caps writes at 31MB to fix a problem with network drives in certain versions of Windows. Am 14.10.2010 21:26, schrieb Chad Warner: > I am experiencing issues with the patch you suggested. I am working > with a repository via its UNC path and it is failing on large files. > I first tried lowing to several different values such as 4MB and still > had problems. I eventually got it to work with the following: > > return write(fd, buf, min(count, 1024 * 27)); > > I didn't notice any real delays with having to call write that many > more times. However, I really don't know how to go about fixing this > issue or validating that this really fixes the problem. Reducing the write cap to 27KB unconditionally sounds pretty drastic to me; it could hurt the local case. I didn't measure it, though, so I might be wrong. Depending on that measurement we perhaps need to find a different solution. Also, 27KB is an odd number. I take it that 28KB won't fix the issue for you? I wonder about the cause of this threshold. Wild guess: network driver bug or other network issue? Which version of Windows do you use on the client? Which OS runs on the server? Do you have any other information that might help in reproducing the problem? Thanks, René -- 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