Hi,

I have a FTP process that successfully uploads a csv file to our current 
FTP server however it will not upload to a new server that we are moving to.

The directory structure of the FTP server I am connecting to is...

\files
    PASReg.csv
    PASHC.csv
    FOCISReg.csv
    EdServ.csv

oFtp := FTPClient():new( cFTPServer, cFTPUser, cFTPPassword, NIL, nPort)
oFTP:Connect(FTP_CONNECT_PASSIVE_MODE)  returns .T.
oFTP:setTransferMode( FTP_TRANSFER_TYPE_ASCII )
oFTP:Directory("*","DHS")  returns empty array
oFTP:CurDir(cServerDir)  returns "\"
oFTP:CurDir()  now returns "\files"

However...

oFTP:Directory("*","DHS") and oFTP:Directory("*.*","DHS") both return an 
empty array.

oFTP:putFile( cLocalPath+"PASReg.csv", "PASReg.csv" )  returns .F.

oFTP:put( "PASReg.csv", cRegCrs )  returns .F.

I also used FileZilla to connect to the server to confirm things and 
noticed that the status log had the following two entries:

Server does not support non-ASCII characters.
Server sent passive reply with unroutable address. Using server address 
instead.

This same routine has worked for years FTPing these files every 60 
seconds.  Prior to Xbase++ 2.0 I was using MarshallSoft.com's FTP 
library fce4xb but, with the desire to reduce the dependency on 3rd 
party libraries I used Alaska's FTPClient().  Fortunately the fce4xb 
does work with the new FTP server but I'm still puzzled as to why Xbase 
is failing me here.  I have tried changing connection modes & transfer 
modes but can not find a solution.

If anyone has any ideas I would appreciate hearing them.

Thanks... Jonathan

jonathan.leeming@the-family-centre.com
Edmonton, Alberta, Canada

Jonathan,

>oFTP:Directory("*","DHS") and oFTP:Directory("*.*","DHS") both return an 
>empty array.

Have you already tried the following: 
* oFTP:Directory()
* oFTP:Directory("")
* oFTP:Directory(, "D")
* oFTP:Directory("", "D")

Some FTP Servers behave peculiar, as they might not allow any wildcard 
options or they might respond with an unexpected "5xx" (Error) Response 
Code, even though no error occurred. Others might send the response data in 
a directory format that the ASInet  FTPClient() class doesn't understand.

I have found that I can work around most of those issues with FCE as well as 
Xb2Net -- using XbFTPClient() -- though, as they are both more flexible and 
allow sending of FTP Commands, such as "SYST", etc.

I also noticed that you use ASCII Transfer Mode:
>oFTP:setTransferMode(FTP_TRANSFER_TYPE_ASCII)

Unless you require the FTP Server to do some ASCII character conversion for 
you during the data transfer, like converting CRLF to LF, etc., I would 
recommend using Binary mode for all transfers.

>If anyone has any ideas I would appreciate hearing them.

If you send me the FTP credentials, I can take a look at the raw FTP Server 
responses, and I may be able to devise a workaround for you.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC

On 3/17/2019 7:18 PM, Andreas Gehrs-Pahl wrote:
> Jonathan,
> 
>> oFTP:Directory("*","DHS") and oFTP:Directory("*.*","DHS") both return an
>> empty array.
> 
> Have you already tried the following:
> * oFTP:Directory()
> * oFTP:Directory("")
> * oFTP:Directory(, "D")
> * oFTP:Directory("", "D")
> 
> Some FTP Servers behave peculiar, as they might not allow any wildcard
> options or they might respond with an unexpected "5xx" (Error) Response
> Code, even though no error occurred. Others might send the response data in
> a directory format that the ASInet  FTPClient() class doesn't understand.
> 
> I have found that I can work around most of those issues with FCE as well as
> Xb2Net -- using XbFTPClient() -- though, as they are both more flexible and
> allow sending of FTP Commands, such as "SYST", etc.
> 
> I also noticed that you use ASCII Transfer Mode:
>> oFTP:setTransferMode(FTP_TRANSFER_TYPE_ASCII)
> 
> Unless you require the FTP Server to do some ASCII character conversion for
> you during the data transfer, like converting CRLF to LF, etc., I would
> recommend using Binary mode for all transfers.
> 
>> If anyone has any ideas I would appreciate hearing them.
> 
> If you send me the FTP credentials, I can take a look at the raw FTP Server
> responses, and I may be able to devise a workaround for you.
> 
> Andreas
> 
Hi Andreas,

Thanks for "stepping in"!

I was using the Directory() to try and figure out what might be going 
on.  Obviously I have some control since oFTP:CurDir() changes and 
returns the current directory but other key details are eluding me!
I added your suggested...

oFTP:Directory()
oFTP:Directory("")
oFTP:Directory(, "D")
oFTP:Directory("", "D")

but all returned an empty array.

I had tried FTP_TRANSFER_TYPE_BINARY previously but tried again with 
your oFTP:Directory() suggestions with the same results.

I have emailed the FTP details to you: Andreas@absolutesoftwarellc.com

Thanks Again!!! Jonathan

jonathan.leeming@the-family-centre.com
Edmonton, Alberta, Canada

Jonathan,

The reason why you can't get a directory listing or file transfer to work 
with ASINet's FTPClient() class, is that your FTP Server is configured 
incorrectly. When going to Passive Mode, the Server should respond with its 
IP Address and the Port Number it is listening on. Normally the IP Address 
is redundant, as it is assumed that it is the same as the one of the command 
connection.

Your FTP Server seems to be a Linux (probably Ubuntu) machine running the 
vsFTPd 3.0.3 FTP Server. Instead of reporting its external (public) IP 
Address, the same one you use to connect to the server, it reports a local 
(private) IP Address, specifically "10.20.0.11", which makes both ASINet's 
FTPClient() as well as Xb2Net's xbFTPClient() trying to connect to that IP
Address.

FileZilla is smart enough to ignore the invalid IP Address and to fall back 
to the original Server IP Address. Marshall Soft's FCE is apparently doing 
the same, or it might simply ignore the provided IP Address all together.

If you have access to the FTP Server -- or if you can contact the FTP 
Server's Admin -- this can probably be fixed quite easily.

Add or edit the following line in the "vsftp.conf" file:
pasv_address=xxx.xxx.xxx.xxx

Instead of the "xxx.xxx.xxx.xxx" enter the external/public IP Address that 
you also use to connect to the FTP Server. That should fix the problem.

I hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC

On 3/18/2019 2:56 AM, Andreas Gehrs-Pahl wrote:
> Jonathan,
> 
> The reason why you can't get a directory listing or file transfer to work
> with ASINet's FTPClient() class, is that your FTP Server is configured
> incorrectly. When going to Passive Mode, the Server should respond with its
> IP Address and the Port Number it is listening on. Normally the IP Address
> is redundant, as it is assumed that it is the same as the one of the command
> connection.
> 
> Your FTP Server seems to be a Linux (probably Ubuntu) machine running the
> vsFTPd 3.0.3 FTP Server. Instead of reporting its external (public) IP
> Address, the same one you use to connect to the server, it reports a local
> (private) IP Address, specifically "10.20.0.11", which makes both ASINet's
> FTPClient() as well as Xb2Net's xbFTPClient() trying to connect to that IP
> Address.
> 
> FileZilla is smart enough to ignore the invalid IP Address and to fall back
> to the original Server IP Address. Marshall Soft's FCE is apparently doing
> the same, or it might simply ignore the provided IP Address all together.
> 
> If you have access to the FTP Server -- or if you can contact the FTP
> Server's Admin -- this can probably be fixed quite easily.
> 
> Add or edit the following line in the "vsftp.conf" file:
> pasv_address=xxx.xxx.xxx.xxx
> 
> Instead of the "xxx.xxx.xxx.xxx" enter the external/public IP Address that
> you also use to connect to the FTP Server. That should fix the problem.
> 
> I hope that helps,
> 
> Andreas
> 
Hi Andreas,

I re-framed your response and passed it on to the company who is 
developing our new website.  They got back to me with...

I spoke with my developers, and they may have given the wrong IP address 
out. The IP address we gave is assigned to the FTP server, but because 
of how the server handles "Floating IP's” we believe you will need to 
use this IP instead: new.IP.Add.ress

Used the new one and that solved the problem.  Thanks so much for your 
assistance!!!

Sincerest Regards... Jonathan

jonathan.leeming@the-family-centre.com
Edmonton, Alberta, Canada

Jonathan,

>Used the new one and that solved the problem. Thanks so much for your 
>assistance!!!

You are welcome.

BTW, have you received any of my emails from Saturday and earlier today, or 
did they all end up in your spam folder? Please let me know if you didn't 
get them, so I can resend them, maybe to a different email address?

Thanks,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC