cURL / Mailing Lists / curl-library / Single Mail

curl-library

a proftpd or curl bug or what?

From: Daniel Stenberg <daniel-curl_at_haxx.se>
Date: Wed, 19 Nov 2003 16:07:39 +0100 (CET)

Hi all

Please bear with me, as this is a rather long and complicated mail, but I do
need some help with some analyzing of what I've found out here.

Mr Nicolas Croiset (cc'ed now) filed bug report #843739, that shows how
libcurl fails to retrieve an FTP file on a persistant connection (it returns
CURLE_PARTIAL_FILE), if the previous transfer failed due to a missing file.

http://sourceforge.net/tracker/index.php?func=detail&aid=843739&group_id=976&atid=100976

The provided example source shows it happen in a nice repeatable fashion.

Using this, I could identify two minor problems in libcurl that were wrong but
even with these two problems fixed, I see very strange results from the FTP
server. The remote server is a ProFTPD 1.2.9 Server, which I believe is a
fairly robust, reliable and well-tested server.

Let me guide you through some VERBOSE output (when running the curlbug.c
program attached to the above mentioned bug report) and point out what I've
seen and what I can't fully understand:

* About to connect() to www.vdl.fr port 21
* Connected to server2.radio-campus.org (212.43.196.114) port 21
< 220 ProFTPD 1.2.9 Server (Serveur FTP) [server2.radio-campus.org]
> USER anonymous
< 331 Anonymous login ok, send your complete email address as your password.
> PASS curl_by_daniel_at_haxx.se
< 230 Anonymous access granted, restrictions apply.
* We have successfully logged in
> PWD
< 257 "/" is current directory.
* Entry path is '/'
> EPSV
< 229 Entering Extended Passive Mode (|||4796|)
* About to connect() to www.vdl.fr port 4796

 This server is clearly modern and supports nice things such as EPSV. We
 connect back to its port 4976.

* Connecting to server2.radio-campus.org (212.43.196.114) port 4796
* Connected the data stream with PASV!
> TYPE I
< 200 Type set to I
> SIZE hd_or.gif
< 213 97
> RETR hd_or.gif
< 150 Opening BINARY mode data connection for hd_or.gif (97 bytes)
* Getting file with size: 97
* Curl_read() = 97 bytes
* Curl_read() = 0 bytes
< 226 Transfer complete.
* Connection #0 left intact
ftp://www.vdl.fr:21/hd_or.gif : curl_easy_perform result = 0

 This is the end of the first file retrieval, everything looks as it should.

* Re-using existing connection! (#0)

 Re-using the control connection.

* Connected to server2.radio-campus.org (212.43.196.114) port 21
> CWD /
< 250 CWD command successful.
> EPSV
< 229 Entering Extended Passive Mode (|||4797|)
* About to connect() to www.vdl.fr port 4797

 We connect to the next port, 4797.

* Connecting to server2.radio-campus.org (212.43.196.114) port 4797
* Connected the data stream with PASV!
> TYPE I
< 200 Type set to I
> SIZE xxxxxxx
< 550 xxxxxxx: No such file or directory
> RETR xxxxxxx
< 550 xxxxxxx: No such file or directory
ftp://www.vdl.fr:21/xxxxxxx : curl_easy_perform result = 19

 The file didn't exist, and libcurl returned failure.

* Re-using existing connection! (#0)

 Third file transfer attempt coming up, re-using the same connection again.

* Connected to server2.radio-campus.org (212.43.196.114) port 21
> CWD /
< 250 CWD command successful.
> EPSV
< 229 Entering Extended Passive Mode (|||4797|)
* About to connect() to www.vdl.fr port 4797

 Hey, look! We get to connect to the *same* port number again only a second
 or two since we last were connected to it. Isn't that fishy? And why does
 it re-use the port number for the fail case and not on the successful case?

* Connecting to server2.radio-campus.org (212.43.196.114) port 4797
* Connected the data stream with PASV!

 ... and we connect fine to it.

> TYPE I
< 200 Type set to I
> SIZE hg_or.gif
< 213 95
> RETR hg_or.gif
< 150 Opening BINARY mode data connection for hg_or.gif (95 bytes)
* Getting file with size: 95
* Curl_read() = 0 bytes

 What? On the first read from this new connection, it returns 0 bytes and thus
 considers the transfer complete! This contradicts the fact that it reports
 size 95...

* Closing connection #0
ftp://www.vdl.fr:21/hg_or.gif : curl_easy_perform result = 18

 ... error 18 is CURLE_PARTIAL_FILE, which in curl's view here is entirely
correct since the server did send a partial file!

(This output is with the latest-CVS libcurl using an additional debug output
that shows how many bytes each Curl_read() has read.)

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
 [[ Do not post private mails to this email address. They won't reach me. ]]
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Received on 2003-11-19