"Dan Harkless" <[EMAIL PROTECTED]> writes:
> Vladi Belperchinov-Shabanski <[EMAIL PROTECTED]> writes:
> > > Yes, it's a known bug and is documented in the current CVS version of
> > > wget.texi. With luck, the fix may be as simple as changing a <= to a <.
> > > It's just that no one's had a chance to look at it. Feel free to peruse
> > > the source and send us a patch.
> >
> > As far as I can understand the problem is that http server does
> > not return Content-Range header if requested range starts at the
> > end of the file (note that this problem is just for http connections
> > ftp is fine). Unfortunately wget code is still not very clear to me
> > and I'm a bit afraid to touch it :) anyway I'll write few notes, so
> > if anyone that is aware could fix it perhaps...
> >
> > http.c:1008: Content-Range header never found and so
> > contrange stays at -1
> >
> > http.c:1126: contrange is still -1 so hs->restval is reset to 0
> > if I get it correctly here is the place that code
> > should be fixed...
> >
> > if hs->restval is requested and is equal to file size so either
> > procedure should be canceled or continued as there are 0 bytes
> > left...
> >
> > currently I cannot do more than this, I'm sorry.
I think I've got this fixed now. The patch I'll submit also fixes
this TODO entry:
* If -c used on a file that's already completely downloaded, don't re-download
it (unless normal --timestamping processing would cause you to do so).
Except I'm not sure it handles timestamping the way this TODO entry
would like to.
