Bugs item #2709004, was opened at 2009-03-24 10:47
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2709004&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: libcurl
Group: None
Status: Open
Resolution: None
Priority: 4
Private: No
Submitted By: timchen119 (timchen119)
Assigned to: Daniel Stenberg (bagder)
Summary: resume when upload from stream (patch included)

Initial Comment:
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 -
ftp://myname:mypass@192.168.23.11/debian-500-i386-CD-1.iso.gz
** Resuming transfer from byte position 46792704
  % 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: (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.

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

>Comment By: Daniel Stenberg (bagder)
Date: 2009-04-06 23:27

Message:
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?

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

Comment By: timchen119 (timchen119)
Date: 2009-03-31 07:07

Message:
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.

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

Comment By: Daniel Stenberg (bagder)
Date: 2009-03-30 19:55

Message:
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.

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

Comment By: Daniel Stenberg (bagder)
Date: 2009-03-24 23:56

Message:
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.

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

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