Bugs item #1053287, was opened at 2004-10-24 14:43
Message generated for change (Comment added) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1053287&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: http
Group: wrong behaviour
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Tomas Pospisek (tpo)
Assigned to: Daniel Stenberg (bagder)
Summary: continue fails on completely downloaded files

Initial Comment:
System is a linux 2.4 box
 
$ curl --version
curl 7.12.2 (i386-pc-linux-gnu) libcurl/7.12.1 OpenSSL/0.9.7d
zlib/1.2.1.1 libidn/0.5.2
Protocols: ftp gopher telnet dict ldap http file https ftps
Features: IDN IPv6 Largefile NTLM SSL libz
 
The file /tmp/X has allready been entirely downloaded:
$ ls -l /tmp/X
-rw-r--r-- 1 tpo tpo 22688683 Oct 24 19:34 /tmp/X
 
If I try to resume download curl fails:
 
curl -C - --fail https://some.apache.webserver/X
** Resuming transfer from byte position 22688683
  % Total % Received % Xferd Average Speed Time Time
Time Current
                                 Dload Upload Total Spent Left
Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
curl: (22) The requested URL returned error: 416
 
This behaveour is problematic, since when scripting curl I have
no idea if the file in question is on disk is the same one as the
one on the server (file1 != file2 <-> sizeof(file1) !=
sizeof(file2)).
 
IMHO curl should determine that download has "failed" because
the file is allready on disk in its entirety.
 
Thanks,
*t

----------------------------------------------------------------------

Comment By: Kovensky ()
Date: 2011-04-25 09:27

Message:
This bug is still present on curl 7.20.1 (i686-pc-cygwin) libcurl/7.20.1
OpenSSL/0.9.8r zlib/1.2.5 libidn/1.18 libssh2/1.2.5, but with a slightly
different behavior. The cygwin build isn't the latest but it's a lot newer
than the closing date of this bug.

curl -C - -L -J -O http://ftp.gnu.org/gnu/binutils/binutils-2.21.tar.bz2
** Resuming transfer from byte position 18742991
  % Total % Received % Xferd Average Speed Time Time Time
Current
                                 Dload Upload Total Spent Left
Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
  0
curl: Saved to filename 'binutils-2.21.tar.bz2'
curl: (18) transfer closed with outstanding read data remaining

This breaks scripts / makefiles due to the non-0 return, and there is
(supposed to be) no outstanding read data remaining.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2004-10-25 08:29

Message:
Logged In: YES
user_id=1110

Thanks for reporting. This problem is now fixed in CVS! Test
case 194 added to verify it.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2004-10-24 19:52

Message:
Logged In: YES
user_id=1110

This works fine for me:

$ curl
https://images-ssl.sourceforge.net/images/head_bg_new.gif -o
dump

$ curl -C -
https://images-ssl.sourceforge.net/images/head_bg_new.gif -o
dump

$ echo $?
0

No error. 7.12.1 and 7.12.2 work fine on this.

Aah! Now I see, you use --fail in there. Ugha. It makes the
operation fail...

Oh that --fail option is one nasty little thing. Ok. I guess
we have work to do...

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1053287&group_id=976
Received on 2011-04-25