#816 resume when upload from stream (patch included)

libcurl (356)

when uploaded data redirected from stdin, it cannot resume because we can't
seekset a stream.


gzip /mnt/2311/debian-500-i386-CD-1.iso -c | curl -T - -C -
** Resuming transfer from byte position 46792704
% Total % Received % Xferd Average Speed Time Time Time
% Current
Dload Upload Total Spent Left
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
curl: (31) Could not seek stream


since we don't really have seek support from stdin,
my following patches checks this situation and do the correct behavior when
upload from ftp/sftp/http.


    • labels: 314652 --> libcurl
    • milestone: 106960 -->
  • Moved from feature-request, since this is not. If we agree to apply these patches they fix bugs. I'll have to reconsider the implications of them once more before I comment on that.

    • priority: 5 --> 4
  • I have a problem with this approach, even though I completely understand why this fix is made and why this way.

    The documentation for SEEKFUNCTION (which is what this piece of the code uses) says:

    "The callback must return 0 on success as returning something else will cause the upload operation to fail."

    These patches instead changes the return code to mean: "if it returns failure, the next approach will be used" which in the upload case means reading and discarding all data up until the resume point.

  • timchen119

    I think you have a good point,
    since change the seekfunction's interface would be more painful, the easiest way to fixed this to me seems to just change CURLOPT_SEEKFUNCTION's document. This function gets called when
    (a). fast forward a file in a resumed upload.
    (b). rewind a stream when doing a HTTP PUT or POST with a multi-pass authentication method. (which is used in transfer.c Curl_readrewind function)

    The callback should still return 0 on success,
    however the error which it returns shouldn't always cause the upload operation to fail, in my opinion it should be case by case, for me, in situation (a) it should tries reading and discarding all data up until the resume point , and in situation (b) it will failed (at least for now, or we could have another patch to make it try another method)

    so if document states when SEEKFUNCTION returns error doesn't always mean upload operation have to fail, than it should be fine for me.

  • But changing the behavior for a return code like that would be to break the ABI and thus an existing app may then act in unintentional ways: not good.

    I think we have to introduce a new return code from the SEEKFUNCTION that means failed-to-seek-pass-it-by-reading. And then we can make the curl tool use this return code if it gets a file on stdin.

    Good/bad? interested in writing the patch more in that style?

  • timchen119

    Ok, as you say we could add a new return code in SEEKFUNCTION and not broke old ABI,
    I've rewrote patches, See if this betters than original one.

  • all patches combined plus my edits

  • Ok, I just submitted seek_func-2.patch to this entry. It is all your patches combined and edited by me.

    Unfortunately test case 33 breaks with this! :-/

  • timchen119

    Oops, I saw the problem now, thanks, I'll send another patch soon after I test it more.

  • timchen119

    fixed problems base on seek_func-2.patch

  • timchen119

    Hi, the patch file seek_func-3.patch should fix the problem that seek_func-2.patch accidentally cause broke when source do support seek_set. and I edited some constants/comments too. I've got the source from cvs and apply this patch then compile and do unit tests, it passes all of tests while some skiped on my platform, please check if this works for you. thanks your patience!

  • Thanks for the report, this problem is now fixed in CVS!

    • status: open --> closed-fixed