Issues downloading from FTP with escaped space character in absolute path

[euangordon]

FluentFTP Version 19.1.2 FTP OS: Unsure FTP Server: Unsure Computer OS: Win 10 x64

I have seen a number of issues and fixes relating to the downloading of ASCII files, but I simply cannot get this to work. Downloading ZIPs and PDFs from the same FTP is working fine. There is no SSL or TLS on this FTP site and I am able to download the files via the standard .NET FTP and via Windows Explorer. The reason for using Fluent is that I download from another FTP which is using TLS.

I am trying to download the file as a stream, I have tried: OpenRead(fullUrl) OpenRead(fullUrl, FtpDataType.ASCII, false); Download(outStream, fullUrl);

Currently getting this in my Output while using Download(outStream, fullUrl);

Download("ftp://ukho.gov.uk/XML%20Catalogues/WK45_17/alrs_paper_catalogue.xml")

OpenRead("ftp://ukho.gov.uk/XML%20Catalogues/WK45_17/alrs_paper_catalogue.xml", ASCII, 0) Command: TYPE A Response: 200 Type set to A.

OpenPassiveDataStream(AutoPassive, "RETR ftp:/ukho.gov.uk/XML%20Catalogues/WK45_17/alrs_paper_catalogue.xml", 0) Command: EPSV Response: 229 Entering Extended Passive Mode (|||64429|) Status: Connecting to 137.135.243.254:64429 Command: RETR ftp:/ukho.gov.uk/XML%20Catalogues/WK45_17/alrs_paper_catalogue.xml Response: 550 The parameter is incorrect. Status: Disposing FtpSocketStream...

Any suggestions?

[robinrodricks]

Do you really need ASCII? Binary is more robust....

[euangordon]

Hi Robin,

I started off using Binary, but was getting a similar error:

OpenRead("ftp://ukho.gov.uk/XML%20Catalogues/WK45_17/alrs_paper_catalogue.xml", Binary, 0) Command: TYPE I Response: 200 Type set to I.

OpenPassiveDataStream(AutoPassive, "RETR ftp:/ukho.gov.uk/XML%20Catalogues/WK45_17/alrs_paper_catalogue.xml", 0) Command: EPSV Response: 229 Entering Extended Passive Mode (|||64427|) Status: Connecting to 137.135.243.254:64427 Command: RETR ftp:/ukho.gov.uk/XML%20Catalogues/WK45_17/alrs_paper_catalogue.xml Response: 550 The parameter is incorrect. Status: Disposing FtpSocketStream...

CloseDataStream() Exception thrown: 'FluentFTP.FtpCommandException' in FluentFTP.dll

[robinrodricks]

Can you url decode the path that you are passing to the download method? I think the %20 is causing the bad parameter response....

[euangordon]

Hi Robin, When I replaced the %20 with a space it could not find the file. But I have found a way to get this to work. If I set the working directory to the folder with the space this works fine. Then I can OpenRead the file.

Are you able to reproduce the issue with escaped characters or is it specific to the FTP I am downloading from?

[robinrodricks]

The first step is to go enable logging (see FAQ) and see which server you have... Maybe we can make a fix for that server in specific... Different servers treat whitespace differently....

[euangordon]

Connect()

Status: Connecting to **:21 Response: 220 Command: USER *** Response: 331 Password required for nautoshark. Command: PASS *** Response: 230 User logged in. Command: FEAT Response: 211 END Response: 211-Extended features supported: Response: LANG EN Response: UTF8 Response: AUTH TLS;TLS-C;SSL;TLS-P; Response: PBSZ Response: PROT C;P; Response: CCC Response: HOST Response: SIZE Response: MDTM Response: REST STREAM Status: Text encoding: System.Text.UTF8Encoding Command: OPTS UTF8 ON Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON. Command: SYST Response: 215 Windows_NT Status: Auto-detected Windows listing parser

[robinrodricks]

Ok will work on it soon...

[euangordon]

Thanks Robin, let me know if there is anything else I can do to help.

[FanDjango]

When I replaced the %20 with a space it could not find the file. But I have found a way to get this to work. If I set the working directory to the folder with the space this works fine. Then I can OpenRead the file.

Given that this issue is from 2017, and much has been changed since then... and also that there is a generic way to avoid these problems (here), lets close this.

FluentFTP will itself eventually migrate towards this approach and these difficulties should become less frequent.