#884 curl doesn't retry after a ftp 550

[Siegfried Gyuricsko]

Here comes a log, which has been made anonymous:

C:\Temp>curl.exe --verbose --disable-epsv --retry 6 --remote-name ftp://*user*:*password*@*host*/pub/*file*
* About to connect() to *host* port 21 (#0)
* Trying *ip_address*... connected
* Connected to *host* (*ip_address*) port 21 (#0)
< 220---------- Welcome to Pure-FTPd [TLS] ----------
< 220-You are user number 7 of 100 allowed.
following lines with code 220 deleted
< 220 You will be disconnected after 15 minutes of inactivity.
> USER *user*
< 331 User *user* OK. Password required
> PASS *password*
< 230-User *user* has group access to: reader
< 230 OK. Current restricted directory is /
> PWD
< 257 "/" is your current location
* Entry path is '/'
> CWD pub
< 250 OK. Current directory is /pub
> PASV
* Connect data stream passively
< 227 Entering Passive Mode (*ip_address*,173,4)
* Trying *ip_address*... connected
* Connecting to *ip_address* (*ip_address*) port 44292
> TYPE I
< 200 TYPE is now 8-bit binary
> SIZE *file*
< 550 Can't check for file existence
> RETR *file*
< 550 Can't open *file*: No such file or directory
* RETR response: 550
* Remembering we are in dir "pub/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connection #0 to host *host*
left intact

curl: (78) RETR response: 550
> QUIT
< 221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
< 221 Logout.
* Closing connection #0
C:\Temp>

Using the parameters retry-delay and retry-max-time as well doesn't change the behaviour.

The following versions of curl have been tried:

curl 7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: Largefile NTLM SSL SSPI libz

curl 7.19.5 (i386-pc-win32) libcurl/7.19.5 OpenSSL/0.9.8k zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: Largefile NTLM SSL SSPI libz

The OS is Windows Server 2003 R2 Standard Edition with SP 2.

[Daniel Stenberg]

Sorry, but this is not a bug. This is the expected behavior for this error.

the --retry option is documented like this:

"If a transient error is returned when curl tries to perform a transfer, it will retry this number of times before giving up."

The keyword here is _transient_. In FTP, that does not include any 5xx errors. The 5xx errors are considered final and they will not be retried by curl.

[Siegfried Gyuricsko]

Thank you for your quick answer. I thought it was a wrong behaviour because of the following statement on http://curl.haxx.se/docs/manpage.html "Transient error means either: a timeout, an FTP 5xx response code or an HTTP 5xx response code." Perhaps this could be clarified in the documentation.

[Daniel Stenberg]

Actually, that is an error in the manual. 5xx errors in FTP are "Permanent Negative Completion reply" while the "Transient Negative Completion reply" is 4xx.

But what's possibly even worse: the curl code does in fact attempt to check for a 5xx code to retry for (even though it should check for 4xx) but as you shown that doesn't work now so it means it won't work for 4xx errors either even if I'd change the code to do that now...

I'll change the manual and I'll have to write up a test case to see how --retry works or not for this.

Thanks for reporting!

[Daniel Stenberg]

Thanks for the report, this problem is now fixed in CVS!