bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Problem using GNU Wget 1.11.4 Windows version


From: JD
Subject: Re: [Bug-wget] Problem using GNU Wget 1.11.4 Windows version
Date: Mon, 19 Mar 2012 14:13:58 -0600

I am sorry -
Range requests??
How can I see that when I run wget -c  ????
You're asking for info I am at a loss as to how to obtain.


On Mon, Mar 19, 2012 at 2:06 PM, Henrik Holst
<address@hidden>wrote:

> Considering that the failing file in question is 3.5GiB it's probably a
> signed 32-bit problem with the size and/or range in either wget or the
> server. Would be interesting to see the range requests done by your version
> of wget around tje.signed 32 limit.
>
> /hh
> Den 19 mar 2012 20:21 skrev "JD" <address@hidden>:
>
>> Thank you brian. But as I already stated in a previous msg,
>> I have no build (compilation) env on my win xp :(
>>
>>
>> On Mon, Mar 19, 2012 at 12:53 PM, Anthony Bryan <address@hidden
>> >wrote:
>>
>> > here's the link for aria2 - you use 'aria2c -M metalinkfile'
>> >
>> > that will guarantee an error free download
>> >
>> > http://aria2.sourceforge.net/
>> >
>> > On Mon, Mar 19, 2012 at 2:50 PM, JD <address@hidden> wrote:
>> > > Sorry! That link led me nowhere...
>> > > So I still need latest wget compiled for windows 32.
>> > >
>> > >
>> > >
>> > > On Mon, Mar 19, 2012 at 12:45 PM, JD <address@hidden> wrote:
>> > >
>> > >> gnu does not distribute windows binaries.
>> > >> So, I will resort to downloading it from from
>> > >>
>> > >>
>> >
>> http://code.google.com/p/mingw-and-ndk/downloads/detail?name=wget-1.13.4-static-mingw.7z
>> > >>
>> > >>
>> > >> On Mon, Mar 19, 2012 at 9:33 AM, Micah Cowan <address@hidden>
>> wrote:
>> > >>
>> > >>> On 03/18/2012 03:24 PM, JD wrote:
>> > >>> > When using wget with the -c option, it does recover and resume the
>> > >>> download
>> > >>> > after network failures. However, after it finishes the download
>> (in
>> > my
>> > >>> case
>> > >>> > downloading
>> > >>> > Fedora-16-i386-DVD.iso), I run the sha256sum on the downloaded ISO
>> > and
>> > >>> it is
>> > >>> > completely different to the value stored in the file of CHECKSUMS
>> on
>> > the
>> > >>> > same
>> > >>> > page URL -
>> > >>> http://mirrors.kernel.org/fedora/releases/16/Fedora/i386/iso/
>> > >>> >
>> > >>> > I downloaded this iso at least twice, with the same result - the
>> > >>> sha256sum
>> > >>> > performed on the file does not match the one at the above URL, and
>> > nor
>> > >>> > does it match the result of sha256sum performed on the previous
>> > >>> downloads
>> > >>> > of the iso file.
>> > >>> >
>> > >>> > So, something is not right with wget!!
>> > >>>
>> > >>> As others have said, using a newer version is probably a good idea.
>> > >>>
>> > >>> However, it's probably also worth asking where you got your wget
>> from,
>> > >>> since we don't really provide official binaries for Wget. Perhaps it
>> > has
>> > >>> a special case...
>> > >>>
>> > >>> It's also conceivable that it could be the server's issue, and isn't
>> > >>> doing HTTP ranged requests correctly. Whether because of wget, or
>> > >>> because of the server, the constantly varying sha256 sums are a clue
>> > >>> that it's not happening correctly (assuming, of course, that all
>> files
>> > >>> are completely downloaded).
>> > >>>
>> > >>> With a partially-downloaded iso, I'd say, make a note of exactly how
>> > >>> many bytes are in the partial download, and take a look at what the
>> > tail
>> > >>> end looks like. Then, when you continue the download, take a look at
>> > >>> that same spot, and see what you find. If HTTP headers suddenly
>> appear
>> > >>> there, or you see what appears to be the beginning of the file at
>> the
>> > >>> continuation point in the file, those are big clues. Also save a
>> copy
>> > of
>> > >>> the original partial download, so you can continue it again and see
>> if
>> > >>> you get different results, or if they're reproducible for the
>> > same-sized
>> > >>> partial download being continued.
>> > >>>
>> > >>> And add the --debug flag to wget to get as much information about
>> > what's
>> > >>> going on as possible. If you manage to find out what's happening,
>> you
>> > >>> may need these logs to know whether to blame wget, or kernel.org.
>> > >>>
>> > >>> Hope that helps,
>> > >>> -mjc
>> > >>>
>> > >>
>> > >>
>> >
>> >
>> >
>> > --
>> > (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>> >   )) Easier, More Reliable, Self Healing Downloads
>> >
>>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]