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
ftp
wrong behaviour
Public
|
Date: 2009-12-10 21:41:32 UTC Thanks for the report, this problem is now fixed in CVS! |
|
Date: 2009-12-09 22:20:39 UTC Actually, that is an error in the manual. 5xx errors in FTP are "Permanent |
|
Date: 2009-12-09 22:13:57 UTC Thank you for your quick answer. I thought it was a wrong behaviour because |
|
Date: 2009-12-09 21:11:55 UTC Sorry, but this is not a bug. This is the expected behavior for this |
| 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 |