I am running camsource 0.6.0 and all is fine except ftpup. I get the following in my log:
[Mar 07 2003 22:11:09 / ftpup] Short ftp response line (" ") in response to command ""
Which seems to indicate that something is a little wrong. the file is not being uploaded. This indicates that the command is not being passed to the ftp server.
I am using an essentially unmodified config file (just the host ,user, password, directory and filename)
..d
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ftpup_read_ftp_resp is expecting all responses to be preceeded with [code]- where [code] is the numeric code for the response. My ISP uses ProFTP which doesn't do this so it gets a failure on a blank line
One possible work around may be to not reuse the ret variable (as the response code for the buffer read and the FTP server code) but to read until ( atoi(buf) && buf[3]!='-') (which is the last line) then break.
Most of the other checks can then be dispensed with.
This then seems to behave.
..d
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah I see how this is working. I just took a look at the ftp rfc and there's really a twist in it that I wasn't taking into account. Thanks for pointing this out. Feel free to send your code to me. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am running camsource 0.6.0 and all is fine except ftpup. I get the following in my log:
[Mar 07 2003 22:11:09 / ftpup] Short ftp response line (" ") in response to command ""
Which seems to indicate that something is a little wrong. the file is not being uploaded. This indicates that the command is not being passed to the ftp server.
I am using an essentially unmodified config file (just the host ,user, password, directory and filename)
..d
A bit more info..
ftpup_read_ftp_resp is expecting all responses to be preceeded with [code]- where [code] is the numeric code for the response. My ISP uses ProFTP which doesn't do this so it gets a failure on a blank line
One possible work around may be to not reuse the ret variable (as the response code for the buffer read and the FTP server code) but to read until ( atoi(buf) && buf[3]!='-') (which is the last line) then break.
Most of the other checks can then be dispensed with.
This then seems to behave.
..d
can you give me an example proftpd login session? or perhaps the address of a ftp server where i can look myself?
Take a look at ftp.pwp.blueyonder.co.uk.
I have working code if you would like it.
(It is working right now..)
..d
Ah I see how this is working. I just took a look at the ftp rfc and there's really a twist in it that I wasn't taking into account. Thanks for pointing this out. Feel free to send your code to me. :)