On Thu, 26 Jun 2003, David Byron wrote:

> $ curl --fail --output emacs.ps.gz --continue-at -
> http://www.gnu.org/manual/emacs/ps/emacs.ps.gz
>
> and let it run to completion. Then, do it again. I saw the message:
>
> ** Resuming transfer from byte position 1029660
> % Total % Received % Xferd Average Speed Time
> Curr.
> Dload Upload Total Current Left
> Speed
> 0 0 0 0 0 0 0 0 --:--:-- 0:00:00 --:--:--
> 0
> curl: (22) The requested file was not found
>
> and the return value is 22.

The reason for this is quite simple: you asked for --fail, which will cause
curl to return an error in case you get an error from the remote HTTP server.

When you ask for a resumed transfer for an already retrieved file, curl will
ask for the following byte and onwards, which the server returns failure for.

In other words, if we already have downloaded N bytes and we ask for a resumed
transfer we ask the server to start sending byte N+1. The server does not have
such a byte for the file, and returns 416 "Requested Range Not Satisfiable".

> Do you agree that it would be nice for curl to return 0 when trying to
> resume download of a file that's already complete?

It would take a strange work-around to "fix" this, if we'd agree that this
actually is a bug.

I would argue that by using --fail, you should get this.

I can't figure out any other way resume on HTTP could work to not cause this
to happen in this scenario. Can you?

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php