[issue25458] ftplib: command response shift - mismatch

2016-12-14 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ftplib <...> >>> ftp.sendcmd('NOOP') '226 Directory send OK.' There are no changes in

[issue25458] ftplib: command response shift - mismatch

2016-12-14 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: * The initial msg253326 has a code snippet using ftplib directly and showing the error. * The linked issue28931 has another snippet that uses ftplib through urllib and results in the same error. There isn't a single mention of "thread" in either. Could you just

[issue25458] ftplib: command response shift - mismatch

2016-12-14 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: Maybe it's me but I still fail to understand what's the issue here. From what I understand from the last message(s) it seems there is complaint about not being able to use ftplib with threads. FTP is a "command - response" protocol which is designed to handl

[issue25458] ftplib: command response shift - mismatch

2016-12-13 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: One more concern about the fix (so that you don't assume I didn't think of this ;) ) - handling of errors signified by the end-of-transfer response. Handling a response in a close handler prevents us from actually checking its code: * destructors like a close ha

[issue25458] ftplib: command response shift - mismatch

2016-12-12 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: I tried to fix `urllib' and ultimately failed. In a nutshell, handling of the aftermath of an `ntransfercmd' is broken. Since `ntransfercmd'/`transfercmd' returns a socket, handling of an end-of-transmission response is done in independently invoked code - upon

[issue25458] ftplib: command response shift - mismatch

2016-12-10 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: Spawned the `urllib' issue to issue28931. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue25458] ftplib: command response shift - mismatch

2016-12-09 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: The solution for the OP's problem is: * after closing the data socket (whether it was returned by `transfercmd()'/`ntransfercmd()' or opened manually), an additional `FTP.getresp()'/`FTP.voidresp()' is required to process the 226 response. The built-in `retrbin

[issue25458] ftplib: command response shift - mismatch

2016-12-09 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: Darn, my problem _is_ in urllib and thus is different that the one in this ticket. Though it too results in a "command response shift". -- ___ Python tracker ___

[issue25458] ftplib: command response shift - mismatch

2016-12-09 Thread Ivan Pozdeev
Changes by Ivan Pozdeev : Removed file: http://bugs.python.org/file45813/ftp_error_illustration.txt ___ Python tracker ___ ___ Python-bugs-lis

[issue25458] ftplib: command response shift - mismatch

2016-12-09 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: Found the root problem: a 1xx response doesn't complete a LIST command, it should wait further for a 2xx one. See RFC 959 section 6 (state diagrams). This could be `urllib`'s rather than `ftplib`'s fault: the former calls low-level subroutines of the latter. --

[issue25458] ftplib: command response shift - mismatch

2016-12-09 Thread Ivan Pozdeev
Ivan Pozdeev added the comment: The current solution looks fishy to me. We should stick to https://tools.ietf.org/html/rfc959 . In particular, 226 is sent when the server closes the auxiliary socket, so the module should react accordingly. Debug printing and/or issuing warnings is an obvious n

[issue25458] ftplib: command response shift - mismatch

2016-12-09 Thread Ivan Pozdeev
Changes by Ivan Pozdeev : -- nosy: +Ivan.Pozdeev versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.7 ___ Python tracker ___

[issue25458] ftplib: command response shift - mismatch

2016-03-09 Thread Peter Pan
Peter Pan added the comment: Here is a small test for the new version. (To see the original ftplib.py version failing copy+paste the code from my initial post into a python file and run) -- Added file: http://bugs.python.org/file42100/test_ftp.py __

[issue25458] ftplib: command response shift - mismatch

2016-03-09 Thread Peter Pan
Peter Pan added the comment: I've updated "ftplib.py" from the 3.5.1 source code release. This should fix issues: http://bugs.python.org/issue25458 http://bugs.python.org/issue25491 -- Added file: http://bugs.python.org/file42099/ftplib.py ___ Pytho

[issue25458] ftplib: command response shift - mismatch

2016-03-08 Thread Peter Pan
Peter Pan added the comment: The problem in my example is ftplib reports a "226" response to command "NOOP" which is nonsense. ftplib received "226" before "ftp.sendcmd('NOOP')" was called. Since "transfercmd()" returns a socket, ftplib was planned to allow for manual transfer socket handling

[issue25458] ftplib: command response shift - mismatch

2016-03-08 Thread Giampaolo Rodola'
Giampaolo Rodola' added the comment: I'm not sure I understood the problem. Perhaps if you provide a patch that would make things more clear and you'd have more chances to see this issue fixed. -- ___ Python tracker

[issue25458] ftplib: command response shift - mismatch

2016-01-16 Thread SilentGhost
Changes by SilentGhost : -- nosy: +giampaolo.rodola versions: +Python 3.6 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mail

[issue25458] ftplib: command response shift - mismatch

2015-10-22 Thread Peter Pan
New submission from Peter Pan: 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