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 loewis
Recipients exarkun, giampaolo.rodola, loewis, nagle, pitrou
Date 2010-10-26.23:18:08
SpamBayes Score 1.7047572e-09
Marked as misclassified No
Message-id <1288135090.66.0.181611372593.issue10202@psf.upfronthosting.co.za>
In-reply-to
Content
I don't quite understand the problem. How exactly do you manage to lose data? The ftp server should send a 226 status code to indicate success over the control connection, and presumably it will do so only after receiving the proper TCP shutdown from its operating system. So regardless of any error handling that ftplib or .close() may fail to perform, I doubt that the problem can actually arise.

As for error checking in close(): I think this is a minor issue for this discussion. Usually, close() will succeed *without* sending all data to the remote system. So looking at the close() status will *not* tell you whether all data has been delivered. You would have to use the SO_LINGER socket option for that.

Even with SO_LINGER turned on, it's pretty pointless to check the close status. While we would be able to tell whether the data has arrived at the remote system, we can't know whether the ftp server has actually read them out of the socket, and written them to disk. So we absolutely need the ftp protocol status to determine the outcome of a STOR (say).
History
Date User Action Args
2010-10-26 23:18:10loewissetrecipients: + loewis, exarkun, nagle, pitrou, giampaolo.rodola
2010-10-26 23:18:10loewissetmessageid: <1288135090.66.0.181611372593.issue10202@psf.upfronthosting.co.za>
2010-10-26 23:18:09loewislinkissue10202 messages
2010-10-26 23:18:08loewiscreate