Well I think that we can rule out the server because it seams to do this the correct way.
I created an "empty" file just the size of which a signed 32-bit integer would have troubles with: henrik@ubuntu:~$ truncate --size 2147483648 Fedora-16-i386-DVD.iso I then turned on capture in Wireshark and told wget to do a resume: henrik@ubuntu:~$ wget -c " http://mirrors.kernel.org/fedora/releases/16/Fedora/i386/iso/Fedora-16-i386-DVD.iso " Now looking at the HTTP request in Wireshark I can see that my version of Wget sends the correct range in order to resume the download: GET /fedora/releases/16/Fedora/i386/iso/Fedora-16-i386-DVD.iso HTTP/1.0 *Range: bytes=2147483648- * User-Agent: Wget/1.12 (linux-gnu) Accept: */* Host: mirrors.kernel.org Connection: Keep-Alive And I can also see that the server does respond in a correct manner: HTTP/1.1 206 Partial Content Date: Mon, 19 Mar 2012 22:14:09 GMT Server: Apache/2.2.22 (Fedora) Last-Modified: Thu, 03 Nov 2011 03:18:38 GMT ETag: "276805c0-e2e0b000-4b0cc0b679f80" Accept-Ranges: bytes *Content-Length: 1658892288 Content-Range: bytes 2147483648-3806375935/3806375936 * Keep-Alive: timeout=5, max=1000 Connection: Keep-Alive Content-Type: application/x-iso9660-image That of course only takes us half-way the problem since we also must ensure that wget fseeks to the correct position and that the server sends from the correct position (another fseek) but that I will not try tonight since the complete download of that file will take 6h for me and I have no time for that at the moment :( Of course seeing a capture of the above using the 32-bit windows version that JD uses would be quite interesting. /HH 2012/3/19 Micah Cowan <[email protected]> > On 03/19/2012 01:13 PM, JD wrote: > > 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. > > Sorry, I was slipping into potential technical explanations. You don't > need to know what ranged requests are. > > As long as you follow the steps I outlined earlier (checking the point > where the corruption happens, and runnin wget with the --debug flag on > (so it gets as much information about what's going on as possible), we > should be able to help you figure out what's going on. > > But again, first try a couple different builds of wget if you can, so we > can eliminate the possibility that you just got your hands on a bad build. > > -mjc > >
