[issue10202] ftplib doesn't check close status after sending file

Change by mike mcleod : -- keywords: +patch pull_requests: +28934 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30747 ___ Python tracker

[issue10202] ftplib doesn't check close status after sending file

mike mcleod added the comment: Working.. should be able to create pull request soon. Note part of suggestions include using SIOCOUTQ, but this does not have an equivalent for windows. And as Murphy's law goes this is likely to be where the problem is! --

[issue10202] ftplib doesn't check close status after sending file

Change by Gregory P. Smith : -- stage: test needed -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10202] ftplib doesn't check close status after sending file

Change by Gregory P. Smith : -- versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.1, Python 3.2 ___ Python tracker ___

[issue10202] ftplib doesn't check close status after sending file

Gregory P. Smith added the comment: [pasting in my investigation that I replied with on a mailing list:] The possible problem does appear real but it likely not frequently observed and is something most people reading the code wouldn't see as it's rather esoteric:

[issue10202] ftplib doesn't check close status after sending file

Change by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10202] ftplib doesn't check close status after sending file

mike mcleod added the comment: I would like to help on this issue. I understand the arguments here but it has been a lone time since this was raised and there does not seem to be any further issues discussed or support for this issue. -- nosy: +mikecmcleod

[issue10202] ftplib doesn't check close status after sending file

Martin v. Löwis mar...@v.loewis.de added the comment: Proper behavior for ftplib when sending is to send all desired data, then call sock.shutdown(socket.SHUT_RDWR). This indicates that no more data will be sent, and blocks until the receiver has acknowledged all their data. I think you

[issue10202] ftplib doesn't check close status after sending file

Giampaolo Rodola' g.rod...@gmail.com added the comment: Proper behavior for ftplib when sending is to send all desired data, then call sock.shutdown(socket.SHUT_RDWR). This indicates that no more data will be sent, and blocks until the receiver has acknowledged all their data. I'm not

[issue10202] ftplib doesn't check close status after sending file

New submission from John Nagle na...@users.sourceforge.net: ftplib doesn't check the status on socket close after writing. This can lead to silently truncated files when sending files with ftplib. A report of truncated files on comp.lang.python led me to check the source code. The ftplib

[issue10202] ftplib doesn't check close status after sending file

Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +giampaolo.rodola stage: - unit test needed versions: -Python 2.5, Python 2.6, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10202

[issue10202] ftplib doesn't check close status after sending file

Antoine Pitrou pit...@free.fr added the comment: It sounds more like an issue in socket.close(), right? -- nosy: +exarkun, loewis, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10202

[issue10202] ftplib doesn't check close status after sending file

Martin v. Löwis mar...@v.loewis.de added the comment: 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

[issue10202] ftplib doesn't check close status after sending file

John Nagle na...@users.sourceforge.net added the comment: Proper behavior for ftplib when sending is to send all desired data, then call sock.shutdown(socket.SHUT_RDWR). This indicates that no more data will be sent, and blocks until the receiver has acknowledged all their data.