Curl version is 7.17.1
  It seems curl built for win32 are using internal ftruncate64
function to truncate file when retry downloading. but the ftruncate64
is only doing file seeking, write 0 byte at the resizing position, and
then seek back to original position. which won't resize the file
actually so the file is still kept with downloaded data before
retrying. then a call to fseek(outs.stream, 0, SEEK_END); is followed
by ftruncate call, which will actually seek the file to outs.init +
outs.bytes instead of correct position (outs.init), and resulting
larger corrupted file on disk.
  _chsize_s should work as a replacement for ftruncate64 in win32, it
use 64-bit integer as the file size, and therefore can handle file
sizes greater than 4 GB. you may view
http://msdn2.microsoft.com/en-us/library/whx354w1(VS.80).aspx for
function details.

  Another possible bug is: curl with --retry option set won't retry if
connection lost during downloading. it will show the message "transfer
closed with xxxx bytes remaining to read" and then exit with
CURLE_PARTIAL_FILE or CURLE_GOT_NOTHING (very rare case when
connection is closed with no any data received yet). I am not sure if
this is working as intended or i am missing with some options. since
when i am doing scheduled download with large number of files, i don't
want some files only partial downloaded and it is hard to check which
one is not fully completed. so i suggest the feature to allow retrying
for those files not fully downloaded (in case you know the file size
and there is remaining bytes from server) if connection is lost, also
the option to do not throw away partly downloaded data and truncate
the file will be helpful when downloading large file and network is
slow or unstable. (e.g: you downloaded 100Mb for a 200Mb file and then
timeout, it is good to keep those 100Mb data before retrying).

   All above are tested in win32 and some http downloads, but it
should apply for other platform and protocol as well.
Received on 2007-12-13