By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,402 Members | 1,047 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,402 IT Pros & Developers. It's quick & easy.

FTP not Returning (Python on Series 60 Nokia)

P: n/a
I'm using the ftp library (layer on top of sockets) to transfer files
from a series 60 to an ftp site. everything works fine, the whole
file gets uploaded but the command never returns! so
i call:

ftp.storbinary('STOR ' + filename,F,1024) # store the image

which does this:

def storbinary(self, cmd, fp, blocksize=8192):
'''Store a file in binary mode.'''
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd)
while 1:
buf = fp.read(blocksize)
if not buf: break
conn.send(buf)
conn.close()
return self.voidresp()

and the 'while 1' never stops. That's my guess anyway. When I run
this in interactive bluetooth mode the storbinary command just hangs
(though the file ends up on the server). i've tried a bunch of
different things, counters, comparisons, everything. there's a signal
library in python but i don't think it's supported in mobile devices.

any suggestions?

thanks!

Mar 29 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
mb*****@gmail.com wrote:
I'm using the ftp library (layer on top of sockets) to transfer files
from a series 60 to an ftp site. everything works fine, the whole
file gets uploaded but the command never returns! so
i call:

ftp.storbinary('STOR ' + filename,F,1024) # store the image

which does this:

def storbinary(self, cmd, fp, blocksize=8192):
'''Store a file in binary mode.'''
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd)
while 1:
buf = fp.read(blocksize)
if not buf: break
conn.send(buf)
conn.close()
return self.voidresp()

and the 'while 1' never stops. That's my guess anyway.


assuming that the connection works properly, the only way to get stuck
in the while loop is if the size of your file is infinitely huge.

so it's probably a connection issue; I suggest adding print statements
around the conn.send and conn.close calls, to make it easier to see
where you get stuck.

setting the debug level (e.g. ftp.set_debuglevel(2)) might also provide
some additional clues.

</F>

Mar 29 '06 #2

P: n/a
Thanks for the 'debug mode' tip. My file is only 24k (a photo) and the
whole thing makes it to the FTP server. It's just the command never
returns so my program cannot continue execution. When I do turn
debugging on, the last command I see is:

*resp* '150 Connection accepted'

Could it be my FTP server? I'm using a windows install of FileZilla.
I did have to make one patch to the ftplib. There is a documented
problem where routers mangle
return text:

227 Entering Passive Mode (192,168,0,3,13,248)

into something like

227 Entring Passive Mode (192,168,0,3,13,248

Pulling off the trailing paren (see:
http://filezilla.sourceforge.net/for...4948c2c84153b).
I edited the parse227 call to not look for the trailing paren.

Anywhere else i can look? I'm running my program line by line in the
bluetooth console and it hangs on the storbinary. When I run the
program directly on the phone as a single exe the same thing happens.

thanks

(Code & output)

Sample Code:

from appuifw import *
from graphics import *
from ftplib import FTP
import camera
import e32
import time
import httplib, urllib
from key_codes import *


picselection = 'e:\\picture.jpg'
ftp = FTP('xx.xx.xxx.xxx') # connect to host
ftp.set_debuglevel(2)
ftp.set_pasv('true')
ftp.login('mike','xxxxx')
F=open(picselection,'rb')
filename = time.strftime("%Y-%m-%d-%H-%M-%S.jpg",time.localtime())
e32.ao_yield()
ftp.storbinary('STOR ' + filename,F,1024) # store the image
e32.ao_yield()
ftp.quit()
F.close()

Debug output:

*cmd* 'USER mike'*put* 'USER mike\r\n'
*get* '331 Password required for mike\r\n'
*resp* '331 Password required for mike'
*cmd* 'PASS *******'
*put* 'PASS *******\r\n'
*get* '230 Logged on\r\n'
*resp* '230 Logged on''230 Logged on'
F=open(picselection,'rb')
filename = time.strftime("%Y-%m-%d-%H-%M-%S.jpg",time.localtime())
e32.ao_yield()
ftp.storbinary('STOR ' + filename,F,1024) # store the image

*cmd* 'TYPE I'
*put* 'TYPE I\r\n'
*get* '200 Type set to I\r\n'
*resp* '200 Type set to I'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entring Passive Mode (69,86,224,242,13,248\r\n'
*resp* '227 Entring Passive Mode (69,86,224,242,13,248'
*cmd* 'STOR 2006-03-29-02-59-13.jpg'
*put* 'STOR 2006-03-29-02-59-13.jpg\r\n'
*get* '150 Connection accepted\r\n'
*resp* '150 Connection accepted'

Mar 29 '06 #3

P: n/a
mb*****@gmail.com wrote:
I'm using the ftp library (layer on top of sockets) to transfer files
from a series 60 to an ftp site. everything works fine, the whole
file gets uploaded but the command never returns! so
i call:

ftp.storbinary('STOR ' + filename,F,1024) # store the image

which does this:

def storbinary(self, cmd, fp, blocksize=8192):
'''Store a file in binary mode.'''
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd)
while 1:
buf = fp.read(blocksize)
if not buf: break
conn.send(buf)
conn.close()
return self.voidresp()

and the 'while 1' never stops. That's my guess anyway. When I run
this in interactive bluetooth mode the storbinary command just hangs
(though the file ends up on the server). i've tried a bunch of
different things, counters, comparisons, everything. there's a signal
library in python but i don't think it's supported in mobile devices.

any suggestions?


Assuming conn is a socket .send() method is not guaranteed to send all
the data. Use .sendall() method. Are you sure the *whole* file is
uploaded?

Serge.

Mar 29 '06 #4

P: n/a
Thanks, but that didn't help either. Since storbinary is being called
from the main script, I can't see where else it could be getting hung
up. Are there any other debugging techniques I could explore?

I'm sending a 24k image and it is viewable on the destination server,
so it's making it over. I can watch the FTP console and see that
transfer hits 24k and then the rate change to 0.0 Kb/s.

I have set up a timeout of 5 seconds on the FTP server at which point I
get a '426 connection aborted' on the python side. So somehow the
sides don't think they have completed the transfer? I could live with
this solution except i'd need a way to ignore the timeout error in
python and continue execution.

I just tried this code with a different file, System.ini, and I have
the same problem.

Mar 29 '06 #5

P: n/a
mb*****@gmail.com wrote:
Thanks, but that didn't help either. Since storbinary is being called
from the main script, I can't see where else it could be getting hung
up. Are there any other debugging techniques I could explore?

I'm sending a 24k image and it is viewable on the destination server,
so it's making it over. I can watch the FTP console and see that
transfer hits 24k and then the rate change to 0.0 Kb/s.

I have set up a timeout of 5 seconds on the FTP server at which point I
get a '426 connection aborted' on the python side. So somehow the
sides don't think they have completed the transfer? I could live with
this solution except i'd need a way to ignore the timeout error in
python and continue execution.

I just tried this code with a different file, System.ini, and I have
the same problem.


It looks like server/client incompatibility or a server bug. Maybe
you'll get some clues here:
http://fetchsoftworks.com/ubb/Forum2/HTML/002542.html
I suggest to try another ftp server.

Serge.

Mar 29 '06 #6

P: n/a
Right. You know I took your suggestion for more print statements and
found the offending line.

[SNIP]
print "close start"
conn.close()
print "close end"
#return self.voidresp()
print "end of everything"

self.voidresp() was hanging! Do I need it? The file seems to run
without it. I also found this:

http://www.techietwo.com/detail-6362036.html

Mar 29 '06 #7

P: n/a
mb*****@gmail.com wrote:
Right. You know I took your suggestion for more print statements and
found the offending line.

[SNIP]
print "close start"
conn.close()
print "close end"
#return self.voidresp()
print "end of everything"

self.voidresp() was hanging! Do I need it?


I don't keep the whole description of ftp protocol in my memory :)
You'd better read the RFC. But I suspect a server is supposed to send
some kind of confirmation that the file was successfully written on a
disk and a client is supposed to wait for such confirmation.

Serge.

Mar 29 '06 #8

P: n/a
Got it. Thanks for your help. :)

Mar 29 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.