Tracked down a small set of problems with some FTP servers. First, some WarFTPD's handle ABOR incorrectly: they don't send a "transfer aborted/successful" followed by "ABOR successful", they just skip to "ABOR successful". This desyncs lftp; the abort changes the expect for "transfer aborted" to "ignore", "ABOR successul" ends up being eaten by that ignore, and ftpclass waits indefinitely for the "ABOR successful" that already came. ex:
lftp [EMAIL PROTECTED]:/video/anime> get Metal_Gear_Sakura.avi ---> TYPE I <--- 200 Type set to I. ---> SIZE Metal_Gear_Sakura.avi <--- 213 2605056 ---> MDTM Metal_Gear_Sakura.avi <--- 213 20001113154228 ---> PORT 24,91,104,252,8,26 <--- 200 PORT command successful. ---> RETR Metal_Gear_Sakura.avi <--- 150 Opening BINARY mode data connection for Metal_Gear_Sakura.avi (2605056 bytes). Interrupt ---> ABOR (missing 4xx "file transfer aborted") <--- 225 ABOR command successful. The server *should* return another 2xx or 4xx response for the transfer (success or aborted) first; it doesn't. This needs a workaround, but I'm not sure where it should go. (We want to make sure we don't lose the control connection; these broken servers are too common to have partial ABOR functionality, even if it *is* the server's fault ...) This might be a little tricky, since 226 might be either response--I think we need to look for "ABOR" in the reply text to see if it's really a misplaced response. (Not portable, but this is a workaround for a specific server, so it doesn't really need to be.) This brings up another minor issue: use-quit. If I "quit" here and attempt to reconnect, it sends a QUIT, and still waits around (for that lost ABOR response), and never really quits unless I close twice. This leaves lftp too prone to confusing stalls due to server bugs. The user shouldn't have to figure out to unset use-quit for these cases ... I'd suggest forcefully closing the connection (even before a QUIT response is received) if the server is reopened, so "clo ; ls" will *always* close and reopen the connection (even if the server is being stupid.) Still send QUIT based on use-quit, though. There are still problems with yet other broken servers and ABOR; I don't think they're handling the telnet sequences correctly, and they need a workaround too, but I don't have ready access to one of those right now to figure out exactly what can be done. I noticed netkit-ftp turns on SO_OOBINLINE if it's available; any idea why it does this? Conceivably it could make some dumb FTP servers behave better, but I can't think of any. (I don't think this has anything to do with any of the above, but it might.) -- Glenn Maynard
