On Apr 28 03:06, Charles Wilson wrote: > antony baxter wrote: > >> ftp> get BCUpdateXP.exe >> 'EPSV': command not understood. >> local: BCUpdateXP.exe remote: BCUpdateXP.exe >> 227 Entering Passive Mode (192,168,1,99,4,110) >> 150 Opening BINARY mode data connection for 'BCUpdateXP.exe' (226020663 >> bytes). >> 0% | >> | 0 0.00 KB/s --:-- ETA >> 426 Data connection: No buffer space available. > > This means that very first call to the cygwin1.dll function 'write(int > networkSocketFd, const void *buf, size_t nbyte)' failed for some reason: > ENOBUFS is not one of the valid error codes for write(), so it's set to > that by something internal to cygwin's implementation of write(). > > e.g. smells like a cygwin (or windows) bug -- cygwin is unable to create a > Mutex or an Event for managing the socket communications (e.g. CreateMutex > or CreateEvent in net.cc: (handler_socket::init_events) failed)
This code only exists in 1.7. The only way to get ENOBUFS in 1.5.x is when Winsock emits it. I see two possible reasons. One is a third-party firewall software which interacts badly with ftpd on the machine with the ENOBUFS problem, the other is ftpd itself. Does ftpd from 1.5 try to write the 215 Megs in one single write call, by any chance? We had this discussion lately and I added a stop-gap measure into 1.7 so that no write to the net writes more than 64K in one go. The problem is that Winsock unintelligibly tries to create a temporary internal buffer the size of the write buffer, regardless of its size. Naturally that can fail, and if it does, you get the error code WSAENOBUFS. The only way around that for 1.5 is to split network writes to smaller chunks. Doing that is much faster on Windows, too, btw. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
