The Off-Key Bard
Technology

Why Does Your Computer Sometimes Say a File Is Corrupted?

Or: how a file can have the right name, the right size, and completely the wrong information. Seeing a file isn't proof that its contents are intact.

Or: How a File Can Have the Right Name, the Right Size, and Completely the Wrong Information

You open a photograph that's sat on your computer for years and half of it is gone. The top looks fine, but the bottom is smeared with strange colors and distorted blocks. Maybe a video stops halfway, a ZIP archive refuses to extract, or a document throws an error saying it's damaged. The file is still there. It has the right name, sits in the right folder, and may even show the size you remember. Yet something has gone wrong.

We tend to think digital files should last forever, since they're just ones and zeros. But those live on physical hardware and software that isn't perfect: drives develop faults, power vanishes mid-operation, software writes bad data, and file-system records fall out of step. Computers defend against most of this, and when the defenses fail, we meet data corruption.

A File Is More Than Its Name and Size

In File Explorer you see a name, type, size, location, and timestamps. Those details come from metadata maintained by the file system, while the contents are stored separately and fetched when an application opens the file. As the recent articles on moving files and on file systems explained, the operating system uses metadata to connect a name to the storage holding its information.

That separation matters because the metadata can stay perfectly valid while the contents are damaged. Windows may know that Vacation.jpg exists, occupies 8,432,176 bytes, and lives at a specific spot. None of that guarantees those bytes still make a valid photograph. The name and size describe the file. They don't prove its contents are right.

Information Lives on Physical Things

A hard drive records magnetic patterns, an SSD holds electrical charge in NAND flash cells, and RAM uses circuits that keep information only while the system runs. All of it is subject to noise, wear, temperature, and component failure, because a computer never observes abstract ones and zeros. It measures physical signals and interprets them as digital values.

A research survey of flash errors, "Errors in Flash-Memory-Based Solid-State Drives," lists the causes. Repeated program and erase cycles wear cells out. Reading one page can nudge the voltage of neighboring cells, called read disturb. And retention errors come from charge leaking away over time after a cell is programmed, which the paper calls the dominant source of flash errors. So the idea that stored data slowly changes isn't a myth, though how much it matters depends on the drive and its age.

Why One Bit Can Matter

Imagine one bit in a long file flips. If it belongs to one pixel, you may never notice; if it changes a length field in a compressed archive, the damage can be dramatic. What matters is the structure of the data, not the count of damaged bits.

A JPEG doesn't store a simple readable list of pixel colors. It holds compressed image data organized in a defined format, and a decoder reconstructs the picture from that structure. Damage a small stretch of the compressed data and you may see a block of distortion. Damage an essential header and the decoder may not recognize the file at all. ZIP archives, videos, documents, databases, and programs all work this way. Applications expect data to follow rules, and when it doesn't, they report corruption. That's why "corrupted file" describes a symptom, not one technical failure.

Corruption Doesn't Always Mean a Bad Drive

A damaged file does not automatically mean the drive is defective. The file may have been incomplete when created, an application may have crashed while saving, or software may have written wrong information. A healthy drive can faithfully store an already corrupted file, since it generally doesn't know whether bytes form a valid photograph.

Interrupted Saves and Caches

Imagine saving a large document when power drops. Depending on how the application and file system handle saving, you might get incomplete data or a file that won't open. Good software writes a new version to a temporary file and replaces the original only once it's ready, but there are limits, especially when data is still in memory or caches.

Saved data passes through several layers: the application, operating-system buffers, and the drive's own caches. That's efficient, but it means "the application finished saving" and "every byte is durably stored" aren't necessarily the same moment, which is one reason letting software shut down normally is worth the wait.

The File System Can Be Damaged Separately

File content corruption and file-system corruption are related but not the same. Contents may be damaged while the file system is healthy, or the metadata may become inconsistent while the contents are intact, in which case the operating system may report volume errors or inaccessible files.

Modern file systems such as NTFS and ext4 use journaling to manage changes safely: before committing certain metadata operations, they record information that helps recovery if the operation is interrupted, so after an unexpected shutdown the system can restore a consistent state. As the previous articles stressed, journaling isn't a backup. It doesn't guarantee that the latest contents of an open document survive, and it can't reconstruct data that was never successfully stored.

How SSDs Quietly Fix Their Own Errors

Because flash cells wear and leak and their charge levels are noisy to read, SSD controllers rely on error-correcting codes, ECC. The controller stores extra mathematical information alongside the data, and when the data is read, that information can detect and correct certain errors. The survey describes ECC as the main defense against raw flash bit errors, with a tradeoff: stronger codes tolerate more errors but cost more chip area and latency. Kingston's explanation adds that its SSD controllers use ECC to detect and correct the vast majority of errors that can affect data, that the NAND stores correction data with each block, and that blocks with excessive errors are retired and replaced from spare blocks.

The idea is the same as sending a message with carefully calculated redundancy: a receiver can notice that something changed and work out the original. The redundancy isn't a complete duplicate of the data. It's calculated so that particular patterns of errors can be identified and fixed. But no practical code can fix every pattern. The survey says data is lost when the raw error rate eventually exceeds the maximum number of errors ECC can correct, and some drives add a backstop, such as parity across flash dies, to reconstruct data when ECC fails.

That makes a corrected error very different from an uncorrectable one. Often an SSD reads wrong raw bits, ECC repairs them, and nobody notices. If errors exceed what the controller can handle, the drive reports an uncorrectable read error and the operating system may be unable to get the data. Kingston cites a typical client-SSD uncorrectable bit error rate specification of approximately one error per 10^15 bits read. That's a reliability rating rather than a guarantee that an error will occur after any particular amount of data, and actual behavior varies by drive design, workload, and operating conditions.

Hard drives have their own version: signal processing, error correction, retries on unreliable sectors, and remapping of bad ones to spares. That hides some imperfections, but mechanical wear and surface damage can still make data unreadable.

Corruption Before the Drive Ever Sees It

Storage isn't the only place data goes wrong. When an application works with a file, the information passes through system memory, and if the RAM is faulty or running at unstable settings, the program can process or save data that was already altered. The corrupted file then lands perfectly on a healthy SSD. The drive did exactly what it was told; the data was wrong before it arrived. That's why repeated unexplained corruption across different files can justify investigating memory as well as storage.

Some systems use ECC RAM, which can detect and correct certain memory errors, commonly single-bit ones. It's valuable in servers and workstations, but it isn't a guarantee against application bugs or every fault. Unstable overclocking can also cause trouble that isn't an obvious crash, since under some conditions incorrect calculations can affect application data. If corruption starts after changing memory timings, enabling an aggressive overclock, or adjusting voltages, return to known stable settings before blaming the drive.

When It's Just a Bad Download

Suppose an archive you downloaded won't extract. The original may be fine, but the download may have been incomplete or interrupted. Before suspecting the SSD, compare the file size or published checksum with what's expected and download it again from the legitimate source.

Detecting Damage: Checksums and Hashes

A checksum is a value calculated from data. If the data changes, the value usually changes too. A familiar example is the cyclic redundancy check, CRC, designed to catch certain accidental errors efficiently. ZIP archives commonly use CRC values to verify extracted contents, which is why an archive tool may report a CRC error: the extracted data doesn't match what the archive claims it should be. That's evidence something is wrong, but it doesn't mean repair is possible.

Cryptographic hash functions such as SHA-256 compute a fixed-length value from a file, and even a tiny change will almost certainly yield a different one. If a developer publishes the SHA-256 of an installer, you can hash your download and compare, and a match is strong evidence your copy matches the data the hash describes. But the check is only as trustworthy as the source of the expected value. An attacker who can replace both a malicious file and its published hash defeats the comparison. A hash helps establish integrity; authenticating the expected value is a separate security question. In PowerShell, Get-FileHash computes a file's hash, and a mismatch shows the files aren't identical, though a match doesn't prove the software is safe.

Detecting Versus Repairing

Many file systems don't check file contents at all. NTFS keeps its structures consistent but doesn't provide comprehensive end-to-end checksums for every file's contents. Others, including ZFS and Btrfs, store checksums and can notice when data changed unexpectedly. The Btrfs documentation describes scrub as a validation pass over all filesystem data and metadata that detects data checksum errors and read errors, and says that on replicated setups such as RAID1 a read-write scrub can repair damage by copying verified data from another replica. Without redundancy, it can detect damage but cannot fix it, because repair needs a known-good copy somewhere. (The docs add that files marked NOCOW have data checksums disabled.)

Detection tells you something is wrong. Repair requires correct information from somewhere else.

"Bit rot" gets used for all of this, but it isn't a single mechanism; problems blamed on it can come from media degradation, retention errors, hardware faults, or undetected write problems. It's a shorthand, not a diagnosis.

Backups and RAID Can Preserve the Damage

Imagine a photo corrupts on Monday and your automated backup copies it on Tuesday over the older version. Now both locations hold the damaged file. A service that mirrors every change will faithfully reproduce accidental deletions, bad edits, and corruption. Version history and separate backups with sensible retention help, and backups need verification too: a backup you've never restored is an untested promise.

RAID is similar: mirroring protects against certain drive failures but isn't a backup, and if software writes incorrect information, the array stores it on several drives. Redundancy isn't the same as verified integrity.

What CHKDSK Can and Can't Do

Windows' CHKDSK examines a volume's file system and metadata. Microsoft's documentation says it checks for logical and physical errors, and that without parameters it only displays status and fixes nothing. It corrects logical errors only if you specify /f. The /r option locates bad sectors and tries to recover readable information, /scan runs an online scan of an NTFS volume, and large-drive /r scans take considerable time because they read every sector.

But CHKDSK is not a universal file-repair tool. Its job is file-system integrity. If a JPEG's image data is damaged, fixing directory structures won't restore missing pixels, and if an application saved an incomplete document, CHKDSK can't know what it should have contained. Microsoft's page even notes that on FAT volumes, declining to convert lost chains to files means Windows fixes the disk without saving the contents of the lost allocation units. Repairing the file system and recovering your information are different tasks.

On a drive that may be physically failing, repair tools modify metadata, and repeated attempts can complicate recovery or stress the hardware. For irreplaceable photos on a drive throwing read errors, preserve what's accessible, copy it where possible, and investigate the hardware first. Drive health data like S.M.A.R.T. offers clues but isn't a perfect predictor. Also check the connection: a failing cable, flaky USB port, or unstable power can interrupt writes, which is why troubleshooting an external drive often starts with a different cable.

What to Do When It Happens

First preserve what remains. Don't keep overwriting the damaged file. Check for autosaved versions, File History or another backup, and cloud version history. If it was a download, compare it with the source or fetch it again. If several unrelated files are corrupted, look at the storage device, memory stability, system logs, and connections instead of blaming one application. And if the drive makes unusual sounds, disconnects, or reports repeated read errors, avoid write-heavy operations until the data is protected. One corrupted download is an inconvenience. Repeated corruption across unrelated files deserves a serious investigation.

Recovery depends on what was lost. A damaged video might yield its intact portions and an archive may still extract some files, but if essential data is gone and no valid copy exists, software can't reliably recreate it. For important documents, the best option is usually a known-good earlier version.

The Bard's Take

Digital files feel permanent because they're sequences of ones and zeros, but those sequences live in magnetic patterns, charge states, and semiconductor circuits, with real physical limits. Computers keep them reliable through error detection, error correction, file-system consistency mechanisms, and careful software, and most of the time it's invisible. An SSD corrects raw flash errors without Windows ever knowing. A file system recovers its metadata after an interrupted operation. An archive tool notices the contents don't match their checksum.

Not everything can be prevented. Power can fail mid-save, an application can write wrong data, unstable memory can alter information before it reaches storage, and a failing drive can hit errors beyond its correction ability. The file can keep its name, size, and location, because none of those guarantee correct contents.

The key is to keep three capabilities apart: detecting damage, correcting damage, and recovering the original. A checksum can tell you the data changed. An error-correcting code may reconstruct the original bits. A backup can restore the file when the current copy can no longer supply the right information. Each solves a different part of the problem.

So being able to see a file proves nothing about its contents. The icon is there, the filename looks right, the size hasn't changed, and somewhere inside millions of bits, the information no longer says what it once did. Digital information doesn't survive because ones and zeros are indestructible. It survives because engineers built layer upon layer of systems designed to notice when the physical world gets them wrong.

Sources

← Back to the Desk — Technology