Yes, there is a thing called bit rot.
But no, it won't affect you unnoticed.
When a drive writes a sector to the platters, it doesn't just write the bits in the same way they're stored in RAM - it uses an encoding to make sure there aren't any sequences of the same bit that are too long, and it adds ECC codes, that allow it to repair errors that affect a few bits, and detect errors that affect more than a few bits.
When the drive reads the sector, it checks these ECC codes, and repairs the data, if neccesary and possible. What happens next depends on the circumstances and the firmware of the drive, which is influenced by the designation of the drive.
- If a sector can be read and has no ECC problems, it's passed to the OS
- If a sector can be repaired easily, the repaired version may be written to disk, read back, and verified, to determine if the error was a random one (cosmic rays ...) or if there is a systematic error with the media
- If the drive determines there is an error with the media, it reallocates the sector
- If a sector can be neither read nor corrected after a few read attempts, on a drive that's designated as a RAID drive, the drive will give up, reallocate the sector, and tell the controller there was a problem. It relies on the RAID controller to reconstruct the sector from the other RAID members, and write it back to the failed drive, which then stores it in the reallocated sector that hopefully doesn't have the problem.
- If a sector can't be read or corrected on a desktop drive, the drive will do a lot more attempts to read it. Depending on the quality of the drive, this might involve repositioning the head, checking if there are any bits that flip when read repeatedly, checking which bits are the weakest, and a few other things. If any of these attempts succeed, the drive will reallocate the sector and write back the repaired data.
(This is one of the main differences between drives that are sold as "Desktop", "NAS/RAID" or "Video surveillance" drives. A RAID drive can just give up quickly and make the controller repair the sector to avoid latency on the user side. A desktop drive will retry again and again, because having the user wait a few seconds is probably better than telling them the data is lost. And a Video drive values constant data rate more than error recovery, as a damaged frame typically won't even be noticed.)
Anyway, the drive will know if there has been bit rot, will typically recover from it, and if it can't, it will tell the controller which will in turn tell the driver which will tell the OS. Then, it's up to the OS to present this error to the user and act on it. This is why cybernard says
I have never witnessed a single bit error myself, but I have seen plenty of hard drives where entire sectors have failed.
the drive will know there's something wrong with the sector, but it doesn't know which bits have failed. (One single bit that has failed will always be caught by ECC).
Please note that chkdsk, and automatically repairing filesystems, do not address reparing data within files. Those are targeted at corruption withing the structure of the filesystem; like a file size being different between the directory entry and the number of allocated blocks. The self-healing feature of NTFS will detect structural damages and prevent them from affecting your data further, they will not repair any data that is already damaged.
There are, of course, other reasons why data may become damaged. For example. bad RAM on a controller may alter data before it's even sent to the drive. In that case, no mechanism on the drive will detect or repair the data, and this may be one reason why the structure of a filesystem is damaged. Other reasons include plain software bugs, blackout while writing the disk (although this is addressed by filesystem journaling), or bad filesystem drivers (the NTFS driver on Linux defaulted to read-only for a long time, as NTFS was reverse engineered, not documented, and the developers didn't trust their own code).
I had this scenario once, where an application would save all its files to two different servers in to different data centres, to keep a working copy if the data under all circumstances. After a few months, we noticed that on one of the copies, about 0.1% of all files didn't match the MD5 sum that the application stored in its database. Turned out to be a faulty fiber cable between the server and the SAN.
These other reasons are why some filesystems, like ZFS, keep additional checksum information to detect errors. They're designed to protect you from a lot more things that can go wrong than just bit rot.
Not specifically related, but similar: http://superuser.com/questions/613702/what-explains-the-garbled-message-start-wandows-ngrmadly-in-text-mode
– Michael Frank – 2016-05-11T22:02:45.110I suppose it could be possible for a damaged read/write head to accidentally apply the wrong charge to the disc, although I've never seen data corruption on that small of a scale. Also, I wouldn't trust Windows to tell me if a drive is failing or not (The message on log-in). I've seen drives die slowly over time without any warning from Windows. – CConard96 – 2016-05-11T22:11:47.710
Of course... the data is stored as bits with relative values of 0 or 1, entropy occurs in all systems, including magnetic and solid state storage. All data degrades over time. – acejavelin – 2016-05-11T22:46:36.233
@acejavelin I'm aware that it's inevitable that data degrades. What I'm wondering is if checksums / other redundancy coupled with the way the filesystem works would be likely to prevent this happening unnoticed (at least when the file is accessed). Updated title for clarity. – topo Reinstate Monica – 2016-05-11T22:54:25.080
Starting with windows 7 the ntfs file system has self healing..https://technet.microsoft.com/en-us/library/cc771388(v=ws.10).aspx
– Moab – 2016-05-11T22:56:43.263Also...https://technet.microsoft.com/en-us/library/cc771388(v=ws.10).aspx
– Moab – 2016-05-11T22:57:47.1602@Moab : I would be more impressed with your second ("Also...") comment if the URL was, in any way whosoever, different from the URL in your first comment. – TOOGAM – 2016-05-11T23:08:24.980
I am not here to impress anyone – Moab – 2016-05-11T23:11:57.123
@topomorto ReFS can (optionally) store data checksums and verify them on reads. FAT and NTFS do not have this feature. Other filesystems that provide data integrity include Btrfs and ZFS, but AFAIK they are not available on Windows. – suriv – 2016-05-12T01:20:24.183
1If you use ReFS on top of a mirrored volume (not parity!) and configure it properly it will checksum file data as well as file system metadata. It will be verified on read (and fixed if necessary) and there is also a scheduled job that will periodically scan the entire volume for detected errors. – davidbak – 2016-05-12T18:36:54.023