Thanks Dan, that is all correct. I missed seeking back the input file, and
when I change it, all works fine.

However this is little weird behavior, because I do:
Set_Easy_Opt(pEasyHandle, CURLOPT_SEEKFUNCTION, my_seek);
I checked several cases in the same scenario and after reconnection I see:
1) file handle is set on the beginning of the file, but there is no partial
file on the server => libcurl works fine, whole file is properly uploaded
2) file handle is set on the beginning of the file, partial file is present
on the server side => libcurl works fine, only rest of the file is uploaded
3) file handle is set somewhere in the middle of the file, partial file is
present on the server side => libcurl works fine, only rest of the file is
uploaded
4) file handle is set somewhere in the middle of the file, but there is no
partial file on the server => *libcurl fails because does not seek back the
file pointer*

I know it is OK and might be "by design", but strange is that libcurl has
all needed information: can know actual seek inside the file (I provided
my_seek function) and knows that there is no such file on the server
(response on SIZE request returns error). In my opinion there is at least a
little lack in the documentation, do not you think?

Greg

On Wed, Apr 18, 2012 at 8:05 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Wed, 18 Apr 2012, Grzegorz Sikorski wrote:
>
> I am using curl (v. 7.24) on ARM processor with linux OS. The box has
>> access to some server (with linux OS) via GPRS connection with VPN tunnel
>> set up. I found some issue with ftp uploading files to server. When the
>> file is big enough sometimes GPRS connection might be lost. In this
>> situation curl discards the connection with following error: *CURL:
>> Transfer has finished with result code: 28("Timeout was reached"),
>> errorBuffer: "Connection timed out after 20002 milliseconds", ID: 18, url:
>> " ftp://10.4.0.1/ftest_02" *This error is also pretty strange, but might
>> be OK (is it?).
>>
>
> Why is it strange? If the TCP stream no longer gets any traffic but it
> isn't "killed", then it will run into your 20 seconds timeout value...
>
>
> When the GPRS connection is recovered, curl tries to continue file
>> transfer.
>>
>
> You mean your application tries to. libcurl will simply do the transfer it
> asks for.
>
> It assumes it already transferred some part and tries to upload rest. But
>> if some reason partial file on the server side (which also lost the
>> connection) was deleted, on ftp SIZE request server replies with packet:
>> *FTP Response: 550 Can't check for file* In this situation I observe
>> strange curl behavior. It assumes it should upload whole file again,
>> because reported total size to upload is valid full file size:
>>
>
> Sounds logical.
>
>
> But instead of retry full uploading, curl uploads only the part that was
>> missing in uploading before the connection was lost.
>>
>
> How would libcurl know about that? This is a second request with (in
> libcurl's eyes) no relation to the previous one. To me this sounds more
> like a flaw in your application. Like for example you didn't seek back to
> the beginning of the file?
>
> --
>
> / daniel.haxx.se
>
> ------------------------------**------------------------------**-------
> List admin: http://cool.haxx.se/list/**listinfo/curl-library<http://cool.haxx.se/list/listinfo/curl-library>
> Etiquette: http://curl.haxx.se/mail/**etiquette.html<http://curl.haxx.se/mail/etiquette.html>
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-04-19