Successive FTP sessions

[cvp]

I can't realize two successive FTP sessions even with the same server, even if I close or quit the session, even if I delete the FTP object at end of a session.
The only way is to remove Pythonista from memory (5 fingers up to apps list, app up)...
Is there another way in the current Pythonista run?

@omz any idea please?

[marcigo36]

I had a similar problem.
Every time after calling ftp.storbinary, it blocked the execution, and locked the uploaded file on my server. However when I killed the pythonista app, the lock got removed, and I found my file to be uploaded successfully.

My solution to this was to set the connection timeout to 5 seconds, so it threw an exception after every storbinary call after 5 seconds.
Since I does not plan to work with big files, I can safely assume that my file got successfully uploaded by then.

This approach can be improved however, for example one can define a callback for storbinary, which gets called after every succesful block upload, so it can be verified whether the process finished or not.

import socket
socket.setdefaulttimeout(5.0)

or in the ftp objects contructor

ftp = FTP(...,timeout=5.0)

[cvp]

Thanks for helping but my problem is unfortunately not the same, and this does not function.
Even if I don't do any transfer, but only open a FTP session, close it, wait some time and try to open a next one, I can't open the next one.

[JonB]

Perhaps you need to post an example.

This worked for me in the beta in both interpreters

import ftplib
F1=ftplib.FTP('ftp.FreeBSD.org',user='ftp')
F2=ftplib.FTP('ftp.FreeBSD.org',user='ftp')
print(F1.sendcmd('CWD pub'))
print('f1 dir')
F1.dir()
print('f2 dir')
F2.dir()

[cvp]

Hi, first, Thanks to help me.
It's really strange, your sample is also ok for me, it's starts two FTP together, it should be not ok if same port...

This sample is not ok.

import keychain
from ftplib import FTP
import time
import console
def test_successive_ftp():
	console.hud_alert('mac')
	user = 'Xxxxx'
	pwd = keychain.get_password('FTPiMac',user)
	try:
		FTP	 = FTP('iMac.local') #connect
		FTP.encoding = 'utf-8'
		FTP.login(user,pwd)
		print('mac')
		print(list(FTP.mlsd('Google Drive/Budget')))
		FTP.quit()
		del FTP
	except:
		console.alert('Mac not accessible','','ok',hide_cancel_button=True)	

	console.hud_alert('adrive')
	user = 'xxxxxx'
	pwd = keychain.get_password('ADrive',user)
	try:
		FTP = FTP('ftp.adrive.com') #connect
		FTP.encoding = 'utf-8'
		FTP.login(user,pwd)
		print('adrive')
		print(list(FTP.mlsd('Google Drive/Budget')))
		FTP.quit()
		del FTP
	except:
		console.alert('ADrive not accessible','','ok',hide_cancel_button=True)	
	
test_successive_ftp()

Even if I use two different variables FTP1 and FTP2, I get he same problem

[cvp]

I asked me if your sample did function because we connect two times to the same server, but I replace one time your server by my NAS and it also functions correctly.
I really don't understand.
I never hoped perform two connections together due to the port limitation, but only two successive connections.

[cvp]

Now, I just retested my code with my two servers, and now it's ok...
I want to cry because I've tried a lot of times, always without success.
I suppose I did something bad, but I don't know what.
Anyway, thanks @JonB , without you, I never did a retry...

[JonB]

@cvp There really is not a port limitation per se. The source port will always use an available port, so there really is no limitation, even making multiple connections to the same server (depending on the server configuration on how many connections it allows).

You never pasted your traceback, so hard to say what was happening, though sounds like it is resolved now..

[JonB]

@cvp actually, one possible issue is that you did

from ftplib import FTP

then overrode the FTP class with an instance variable named FTP.
So the second call to FTP is actually referring to the first instance, not ftplib.FTP class constructor anymore. So even if you renamed the second variable, the first one led to the confusion. The second try block would have resulted in a NameError or TypeError depending on whether an exception was caught in the first try. The try-except prevented you from seeing the real error.

[cvp]

Sorry for my late answer...
You did find the reason, I used the same name for the import and for the class instance.
Shame on me and thanks a lot to you @JonB
It's not the first time, and surely not the last one, that you're my rescuer 😇

[cvp]

@JonB and yes, my error interception code was not very useful, now replaced by

except Exception as e:
	console.alert('Mac not accessible','error:'+str(e),'ok',hide_cancel_button=True)