On Thu, Aug 26, 2010 at 04:03:00PM +0200, Carlos E. R. wrote:
On 2010-08-26 14:38, Basil Chupin wrote:
On 26/08/2010 19:17, DenverD wrote:
i'm pretty sure the answer to his problems is to fetch a full and correct image...
Yeah, I tried that before posting, but got the same md5sum every time.
I've seen such responses before - and they puzzle me.
Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature?
Modern times, that...
Yes, but it appears that http/ftp don't have that feature.
Turns out, that a broken proxy was the problem. The proxy delivered a Content-Length header of about 51 MB. So the client has never had a chance to do a correct download. Guess the proxy had problems with the 4GB limit.
Instead, people could use the metalink "link" to make the download with a good metalink downloader, because that protocol _can_ guarantee a correct download, correcting errors. I use aria2c.
Caveat: it requires that the metalink metadata contains error correction blocks. The DVD links at suse do. The system works by redownloading a bad block, and the dvd link has 129 such blocks of ~33 MB.
With a wrong Content-Length header, all chances are gone, IMHO.
Once a download is bad, probably rsync is more efficient at correcting it. Do we have this info easily found in the wiki, near the download page?
A torrent downloader can also correct it.
But what do you do if your only access is HTTP via proxy? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org