This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author peterpan
Recipients peterpan
Date 2015-10-22.10:35:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
In-reply-to
Content
When handling the transfer socket manually the asynchronous status message "226 transfer complete" on the control socket is falsely taken as response for the last sent command.
ftplib reads the response too late and the command/response order becomes invalid.

I can avoid that by using the undocumented ftplib internal method FTP.getline() after the transfer socket is closed and not sending more commands while the transfer socket is open.

It would be useful, if ftplib empties the response socket buffer before sending the next command. But maybe the best solution is an optional function callback when the "226" response appears, while it is ignored when not matching the last sent command.

Example code that triggers the problem:

import ftplib
import socket
import re


ftp = ftplib.FTP()
ftp.set_debuglevel(1)
ftp.connect('ftp.debian.org', timeout=10)
ftp.login('anonymous','user@example.com')
ftp.sendcmd('TYPE A')

s = ftp.transfercmd('LIST')

'''
#manual transfer socket - should result in same behaviour
r = ftp.sendcmd('EPSV')
r = re.search('\|([0-9]+)\|', r)
port = int( r.group(1) )
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('ftp.debian.org', port))
ftp.sendcmd('LIST')
'''

fp = s.makefile('r')
fp.read()
fp.close()
s.close()

#ftplib falsely sees "226 transfer complete" as response to next command
ftp.sendcmd('NOOP')
History
Date User Action Args
2015-10-22 10:35:52peterpansetrecipients: + peterpan
2015-10-22 10:35:52peterpansetmessageid: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
2015-10-22 10:35:52peterpanlinkissue25458 messages
2015-10-22 10:35:52peterpancreate