How does a downloaded ISO get corrupted?

Question

Possible Duplicate:
Is it possible to get corrupted download with http?

I downloaded an ISO for fedora. Went to install it as a VM. It failed 5 times the installer. The warning for the failure was "possible corrupted install image". How does a downloaded ISO get corrupted?

(I am stubborn and didn't want to download the huge file again) So finally after 5 failures I went to download the ISO again... and I thought... maybe the warning was correct.

So instead of blindly trusting the download I went to verify the ISO using the supplied "sha256" checksum. "!well blow me down Olive Oil!" Sure enough the first downloaded ISO failed the failed the checksum test!

My question is this... What is the most likely way (or ways plural) that my ISO got corrupted?

UPDATE:

• Both downloaded ISO files have the same total number of bytes.
• How did I download the ISO file? I downloaded via a link in browser. And then the browser did the download. So http.
• How is my computer connected to the internet, physical/wireless? Wireless. Wifi (unsecured... I am aware of the unsecured...).

Solution 1

HTTP and FTP do not have built-in checksums. TCP provides basic checksumming methods (padding and ones-complement addition), but these do not account for data being corrupted either before transit, during storage (power failure), and after storage (corrupted hard drive).

BitTorrent, on the other hand, checksums each block received (a few hundred kilobytes to a few megabytes, depending on torrent) using a cryptographically strong(er) method (either CRC32 or MD5), which, on top of the TCP checksum, is almost guaranteed to be correct.

However, no amount of checksumming will prevent against corruption after the file has been saved. (power failure during download for example)

Solution 2

One notorious way to download a corrupted file is to use FTP in text mode for a non-text file (such as an ISO).

In text mode, the FTP protocol allows for translation of line-endings, so when downloading from Unix to Windows, every 0x0a is replaced by 0x0d 0x0a (LF -> CR LF) which is catastrophic for the integrity of a binary file where 0x0A can occur as part of the data not representing a newline / linefeed (LF)

Comments

[sawdust]

How did you download the image (bittorrent or http or ftp)? How is your PC connected to the Internet?

[user3660103]

@TrevorBoydSmith Are you sure that the second image was actually downloaded from same server? Load balancing on the other side might have moved you to another server that has good image. Also you are being very aggressive to other people who are spending their time to help you. We can't know things that you know and therefore must list some likely reasons, even if they aren't applicable in your particular case.

[Trevor Boyd Smith]

thanks for the link to the duplicate. the duplicate is talking about exactly what i needed.

[user1686]

BitTorrent uses SHA-1 hashes, and most (all?) clients are able to re-verify already downloaded data upon user request. CRC32 doesn't even count as "cryptographic"; it's just a checksum, like TCP's algorithm.

[Trevor Boyd Smith]

i never mentioned any sort of "there was a power failure"... so i don't really see why your answer is peppered with "during storage (power failure)" "(power failure during download for example)"

[user5249203]

Added 2nd para to answer.

[JJ_Australia]

@grawity: Poor wording.

[Florenz Kley]

actually, translation on newlines depends on the platform. But I think this is lost on Mr. Smith. Thanks for the patience Brick, adding the explanation.

[Trevor Boyd Smith]

i should not have started my post with "not helpful". that was too not constructive on my part.

[Trevor Boyd Smith]

thank you for elaborating your answer I can now understand why using ftp in text mode would affect the download of a binary file.

[Trevor Boyd Smith]

i deleted the comment i posted because it was not the terribly constructive. instead of this comment i updated the question.