Donate Share

curl and libcurl

Tracker: Bugs

5 curl doesn't retry after a ftp 550 - ID: 2911279
Last Update: Comment added ( bagder )

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.


Siegfried Gyuricsko ( sgyuricsko ) - 2009-12-09 09:10:39 UTC

5

Closed

Fixed

Daniel Stenberg

ftp

wrong behaviour

Public


Comments ( 4 )

Date: 2009-12-10 21:41:32 UTC
Sender: bagderProject AdminAccepting Donations

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


Date: 2009-12-09 22:20:39 UTC
Sender: bagderProject AdminAccepting Donations

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!


Date: 2009-12-09 22:13:57 UTC
Sender: sgyuricsko

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.


Date: 2009-12-09 21:11:55 UTC
Sender: bagderProject AdminAccepting Donations

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.


Attached File

No Files Currently Attached

Changes ( 9 )

Field Old Value Date By
close_date - 2009-12-10 21:41:32 UTC bagder
status_id Open 2009-12-10 21:41:32 UTC bagder
resolution_id Accepted 2009-12-10 21:41:32 UTC bagder
resolution_id Invalid 2009-12-09 22:20:39 UTC bagder
status_id Pending 2009-12-09 22:20:39 UTC bagder
close_date 2009-12-09 21:11 2009-12-09 22:20:39 UTC bagder
status_id Open 2009-12-09 21:11:55 UTC bagder
close_date - 2009-12-09 21:11:55 UTC bagder
resolution_id None 2009-12-09 21:11:55 UTC bagder