On Fri, 23 Jan 2004, Gisle Vanem wrote:

> * Getting file with size: 2876516042
>
> 0 2743M 0 1024 0 0 431 0 1853:13:27 0:00:02 1853:13:24 431
> 0 2743M 0 5404 0 0 2108 0 378:57:49 0:00:02 378:57:46 23297
> 0 2743M 0 60528 0 0 17605 0 45:23:06 0:00:03 45:23:03 119k
>
> The huge initial ETA makes the progress line a bit too long. So successive
> lines should clear the old trailing text.

As soon as the line has once wrapped. our simple terminal-trick that uses \r
to go back on the same line no longer works. We're then on a new line and
can't go back!

I can only think of one way to prevent this ugliness to happen, and that is to
make sure that the line never grows bigger than 79 columns and to make sure
that we always print the line using the same width. Currently, getting a time
that estimates to 4-digit hours don't fit!

I do however believe that we have a few spaces in the line that we _can_ save
to use for additional ETA-widths. We should perhaps consider a fix for when
that isn't enough anyway, since getting a 64bit filesize with 1byte/sec
transfer speed will no doubt cause an ETA that is too wide for us... :-)

> And >999M replaced by xx.xG.

Actually, 9999M is ok too. We have 5 letters saved for the transferred amount.

> Note there is still problems with MSVC v6, SIZEOF_CURL_OFF_T and 'long long'
> etc., but MingW has no problems with huge files.

What problems are there (left) with our current code and MSVC v6?

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn