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-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-03-30