On 2010/02/11 23:44, Daniel Dickman wrote: > ftp(1) will reliably stall for me when doing uploads. I tracked the > problem down to the keep-alive option. Not sure how widespread this issue > is as I'd imagine it depends on what server is on the receiving end. But > here's a sample transcript which gets stuck every time and requires me to > kill the process... the patch below turns off this functionality by > default as it doesn't really work all that well for me for uploads. > (Downloads on this same server work fine though).
ftp(1) doesn't read until after the transfer finishes, so the server has to queue a big batch of "200 NOOP command successful" or similar replies and send them in a batch at the end of the transfer. Every other ftp client that I've investigated which has this option reads the replies after each line, which is more friendly to the server. I'm not sure if it's implicated in this problem, but I think it's fairly likely. I've played around with moving getreply() into send_noop_char() but something more than this is needed as it freezes after trying to read the first response. One problem with disabling keepalive is that some people behind crappy nat gateways need it, and there's no easy way to set this from the installer (without adding ugly questions, anyway), but OTOH pushing them towards using http might be a more sane work- around there...
