[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 Unsubscri

[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: https://blog.netherlabs.nl/

[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: https://mail.

[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 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 misunderstand.

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

Giampaolo Rodola' 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 sure about th

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

John Nagle 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. "socketmodule.c" handles this right.

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

Martin v. Löwis 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 shutdown from its ope

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

Antoine Pitrou added the comment: It sounds more like an issue in socket.close(), right? -- nosy: +exarkun, loewis, pitrou ___ Python tracker ___ ___

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

Changes by R. David Murray : -- nosy: +giampaolo.rodola stage: -> unit test needed versions: -Python 2.5, Python 2.6, Python 3.3 ___ Python tracker ___

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

New submission from John Nagle : "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" module does sending by