On 6/19/2013 1:25 AM, Edward Berner wrote:
On 6/18/2013 7:56 PM, Richard Hipp wrote:
On Tue, Jun 18, 2013 at 10:52 PM, Edward Berner <[email protected]
<mailto:[email protected]>> wrote:
I was able to reproduce a similar behavior, and I think it has to
do with the size of those files.
I created a 200 MB file and a 150 MB file using dd from
/dev/arandom. I added those to a new repository on an OpenBSD
system and was able to successfully clone it to a CentOS Linux
system but it did not successfully clone to a Windows XP SP3 system.
I was able to clone from Linux to Win8 successfully. Do you think it
is some kind of XP-specific problem?
I'm surprised, but yeah, its looking that way. I just ran the test
again using the same fossil binary on XP and Windows 7. The clone
failed on XP but succeeded on (64 bit) Windows 7. It also succeeds on
32 bit Vista but fails on Windows 2000 (I had to use a different
binary on Windows 2000).
As a sanity check I served up a copy of Fossil's own repository in the
same way as my test repository. All systems were able to successfully
clone it.
I think I figured out part of the problem.
Way down in http_socket.c, there is no error handling in
socket_receive() and socket_send().
In socket_receive(), I'm seeing a -1 return from recv(), and
WSAGetLastError() returns 10055 which is WSAENOBUFS. According to the
MSDN Library that means "No buffer space available. An operation on a
socket could not be performed because the system lacked sufficient
buffer space or because a queue was full."
(I don't know yet what the WSAENOBUFS is about or how to avoid or handle
it....)
--
Edward Berner
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
