From 18371aaff999d4862a32d060f03d8f668e8fa1b1 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Mon, 8 Dec 2008 20:20:51 +0000 Subject: - Fred Machado posted about a weird FTP problem on the curl-users list and when researching it, it turned out he got a 550 response back from a SIZE command and then I fell over the text in RFC3659 that says: The presence of the 550 error response to a SIZE command MUST NOT be taken by the client as an indication that the file cannot be transferred in the current MODE and TYPE. In other words: the change I did on September 30th 2008 and that has been included in the last two releases were a regression and a bad idea. We MUST NOT take a 550 response from SIZE as a hint that the file doesn't exist. --- lib/ftp.c | 5 ----- 1 file changed, 5 deletions(-) (limited to 'lib') diff --git a/lib/ftp.c b/lib/ftp.c index 547ad77d9..209faf7d7 100644 --- a/lib/ftp.c +++ b/lib/ftp.c @@ -2190,10 +2190,6 @@ static CURLcode ftp_state_size_resp(struct connectdata *conn, curl_off_t filesize; char *buf = data->state.buffer; - if((instate != FTP_STOR_SIZE) && (ftpcode == 550)) - /* the file doesn't exist and we're not about to upload */ - return CURLE_REMOTE_FILE_NOT_FOUND; - /* get the size from the ascii string: */ filesize = (ftpcode == 213)?curlx_strtoofft(buf+4, NULL, 0):-1; @@ -3169,7 +3165,6 @@ static CURLcode ftp_done(struct connectdata *conn, CURLcode status, case CURLE_UPLOAD_FAILED: case CURLE_REMOTE_ACCESS_DENIED: case CURLE_FILESIZE_EXCEEDED: - case CURLE_REMOTE_FILE_NOT_FOUND: /* the connection stays alive fine even though this happened */ /* fall-through */ case CURLE_OK: /* doesn't affect the control connection's status */ -- cgit v1.2.3