[issue2628] ftplib Persistent data connection

mike mcleod added the comment: You're welcome. Regards, Mike On Tue, 2 Nov 2021 at 05:52, Ethan Furman wrote: > > Ethan Furman added the comment: > > Ah. Well, in that case closing seems like the best idea. > > Thank you, Jonathan, for getting the CLA signed and providing perspective. > >

[issue2628] ftplib Persistent data connection

Ethan Furman added the comment: Ah. Well, in that case closing seems like the best idea. Thank you, Jonathan, for getting the CLA signed and providing perspective. Thank you, Mike, for moving this issue forward. -- resolution: -> rejected stage: patch review -> resolved status:

[issue2628] ftplib Persistent data connection

Jonathan Bell added the comment: I should rephrase: There doesn't seem to be a practical way to verify BLOCK transmission mode against actual servers in the wild. As the Wikipedia article that Giampaolo referenced points out, BLOCK mode is a rarity that was primarily supported only by

[issue2628] ftplib Persistent data connection

Ethan Furman added the comment: I would like to have the issue fixed instead of just closed. Jonathan, you say there is no practical method to verify that the block transmission mode exists -- so it's only useful if the user knows that it exists? If the user tries it and the server does

[issue2628] ftplib Persistent data connection

Jonathan Bell added the comment: No practical method exists to verify BLOCK transmission mode, which as mentioned earlier, was rarely implemented even when this issue was opened. Given that reality, I'm inclined to close this issue. -- ___ Python

[issue2628] ftplib Persistent data connection

mike mcleod added the comment: I am happy to do any testing. My reason for getting involved is I am new to helping with Cpython and thought this may be the least intrusive way of getting started with something that nobody really cares about that much. Hence, the oldest issue I see can be

[issue2628] ftplib Persistent data connection

Jonathan Bell added the comment: This issue is 13 years old. The original 2008 patch was used in a production environment against an OpenVMS server identifying itself as MadGoat. That use case involved downloading documents only, and no write permission was available. Therefore the patch

[issue2628] ftplib Persistent data connection

Giampaolo Rodola' added the comment: Hello. I added some initial comments to the PR, but I'm sort of skeptical about this. It must be noted that: 1) very few FTP servers probably support this feature (https://en.wikipedia.org/wiki/File_Transfer_Protocol#Data_transfer_modes) 2) the specs

[issue2628] ftplib Persistent data connection

Change by Jonathan Bell : -- pull_requests: +27604 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/29337 ___ Python tracker ___

[issue2628] ftplib Persistent data connection

Ethan Furman added the comment: If you're familiar with git and GitHub, can you create a PR? Otherwise, an updated patch here and we'll work on getting it merged. -- ___ Python tracker

[issue2628] ftplib Persistent data connection

Jonathan Bell added the comment: The CLA is signed, and I'm again able to work on this. I was able to update this locally for Python 3 with a minimal test case. What specifically were you looking for? -- ___ Python tracker

[issue2628] ftplib Persistent data connection

mike mcleod added the comment: Hi Ethan, Thanks, awaiting reply.. Regards, Mike On Tue, 26 Oct 2021 at 01:36, Ethan Furman wrote: > > Ethan Furman added the comment: > > We don't have a CLA from jbell. I've sent an email asking him to do so... > we'll see what happens. > > -- >

[issue2628] ftplib Persistent data connection

Ethan Furman added the comment: We don't have a CLA from jbell. I've sent an email asking him to do so... we'll see what happens. -- nosy: +ethan.furman ___ Python tracker

[issue2628] ftplib Persistent data connection

mike mcleod added the comment: Hi, I would like to help on this issue. -- nosy: +mikecmcleod ___ Python tracker ___ ___

[issue2628] ftplib Persistent data connection

Changes by Terry J. Reedy tjre...@udel.edu: Removed file: http://bugs.python.org/file10025/ftplib.py.blockmode.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2628 ___

[issue2628] ftplib Persistent data connection

Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.2 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2628 ___ ___

[issue2628] ftplib Persistent data connection

Changes by Terry J. Reedy tjre...@udel.edu: -- stage: - unit test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2628 ___ ___

[issue2628] ftplib Persistent data connection

Jonathan [EMAIL PROTECTED] added the comment: Yeah, I'm glad to see a test suite. I've only skimmed the test, but it seems like an excellent starting point. Initial thoughts for updating the tests: - Need a cmd_mode to handle the MODE command. - Suite cmd_retr logic needs to keep dtp connection

[issue2628] ftplib Persistent data connection

Gregory P. Smith [EMAIL PROTECTED] added the comment: sure go for it, i haven't had time to look at the latest patch myself. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 ___

[issue2628] ftplib Persistent data connection

Giampaolo Rodola' [EMAIL PROTECTED] added the comment: An actual test suite for ftplib is now available. Should we reconsider revamping this issue? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 ___

[issue2628] ftplib Persistent data connection

Changes by Jonathan [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10311/ftplib.py.blockmode.patch.2 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 __ ___

[issue2628] ftplib Persistent data connection

Changes by Jonathan [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10312/ftplib.rst.blockmode.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 __ ___

[issue2628] ftplib Persistent data connection

Jonathan [EMAIL PROTECTED] added the comment: I've attached two new files. The first swaps the array.array usage for struct.unpack. The second simply modifies the rst documentation. I'm not sure how we'd do any tests for FTP without making use of an actual server. In a quick check of servers,

[issue2628] ftplib Persistent data connection

Gregory P. Smith [EMAIL PROTECTED] added the comment: rather than using the array.array for your three byte header with manual parsing, please use struct.unpack. Whats a good way to test that this works? It'd be nice to have a unit test (a test_ftplib_net.py perhaps?) though I realize ftplib

[issue2628] ftplib Persistent data connection

Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 __ ___ Python-bugs-list mailing list

[issue2628] ftplib Persistent data connection

New submission from Jonathan [EMAIL PROTECTED]: About a year ago I found myself fighting a broken FTP server that couldn't handle multiple passive data transfers through a firewall or NATed connection. Thankfully, this same problem server supports block transmission mode, which allows a client

[issue2628] ftplib Persistent data connection

Jonathan [EMAIL PROTECTED] added the comment: Here's the debug output when the transfers are going well. Added file: http://bugs.python.org/file10026/debug.log __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 __