How does a downloaded ISO get corrupted? [duplicate]
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...).
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)
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)