Hi Daniel,
> On Thu, 14 Jun 2007, Guenter Knauf wrote:

>> curl: (18) transfer closed with -1 bytes remaining to read, indeed the
>> downloaded files are 1 byte longer...

> Wow. I don't see what libcurl would do to cause this. I would suspect
> "something else". Can you check what the extra byte is and where in the
> stream it ends up?
I've tested with a binary test file which is 512 bytes long, and contains 2x 0-255 as byte values;
the extra byte appended it a 0 ...
same file fetched with http has correctly 512 bytes.

Also just tested a text file, and same issue; just checked with -v:
...
< 250 Directory successfully changed.
> EPSV
* Connect data stream passively
< 229 Entering Extended Passive Mode (|||62279|)
* Trying 140.90.128.71... connected
* Connecting to 140.90.128.71 (140.90.128.71) port 62279
> TYPE I
< 200 Switching to Binary mode.
> SIZE ETNN.TXT
< 213 418
> RETR ETNN.TXT
< 150 Opening BINARY mode data connection for ETNN.TXT (418 bytes).
* Maxdownload = -1
* Getting file with size: 418
{ [data not shown]
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 418 100 418 0 0 283 0 0:00:01 0:00:01 --:--:-- 283*
transfer closed with -1 bytes remaining to read
* Received only partial file: 419 bytes
100 418 100 419 0 0 283 0 0:00:01 0:00:01 --:--:-- 250*
Closing connection #0

curl: (18) transfer closed with -1 bytes remaining to read

other ftp transfers work though from same NetWare box, f.e. ftp commandline, and from PHP with ftp ectension...

Guen.
Received on 2007-06-14