#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.


1 2 3 > >> (Page 1 of 3)
    • 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.

1 2 3 > >> (Page 1 of 3)