Verifying a file arrived intact, without trusting the progress bar

The Finder’s progress bar reaches the end, the window closes, and you assume the file arrived. Usually it did. Occasionally it did not, and the failure is silent: the file is the right size, it opens in the Finder, and something inside it is wrong.

Silent corruption is rare on a healthy internal drive and considerably less rare across USB enclosures, ageing external drives, network shares and long transfers. If the file matters, a checksum takes about the same time as a coffee refill and turns “probably fine” into “verified”.

What a checksum is, in one paragraph

A checksum runs over every byte of a file and produces a fixed-length string. Change any single byte and the string changes completely. Compute it on the source, compute it on the copy, compare the two: identical strings mean the copy is bit-for-bit identical to the original. Different strings mean something changed in transit, even if both files are the same size.

macOS ships with the tools. There is nothing to install.

The one command you need

shasum -a 256 /path/to/original.mov

That prints a 64-character string followed by the filename. Run the same command against the copy:

shasum -a 256 /Volumes/Backup/original.mov

If the strings match, the file is intact. Drag files from the Finder into the Terminal window to fill in paths rather than typing them.

For a quick visual comparison of two files at once:

shasum -a 256 ~/Movies/clip.mov /Volumes/Backup/clip.mov

Both lines print together, and mismatches are obvious because the strings diverge within the first few characters.

Verifying a whole folder

Checking files one at a time does not scale. Compute a manifest for the source, then verify the destination against it.

From inside the source folder:

cd ~/Movies/Project
find . -type f -exec shasum -a 256 {} \; > ~/Desktop/manifest.txt

Then, from inside the destination folder:

cd /Volumes/Backup/Project
shasum -a 256 -c ~/Desktop/manifest.txt

Every file prints either OK or FAILED. To see only problems:

shasum -a 256 -c ~/Desktop/manifest.txt 2>/dev/null | grep -v ': OK$'

Silence from that command means everything verified. This is the closest thing to proof that a backup is genuine, and it is worth doing once on any archive you intend to rely on.

The faster option for large transfers

Computing a checksum reads the entire file, so verifying 500 GB takes real time. For large jobs, get the verification for free by using a tool that does it as part of the copy.

rsync compares source and destination and re-transfers anything that differs:

rsync -avc --progress ~/Movies/Project/ /Volumes/Backup/Project/

The -c flag is the important one: it tells rsync to compare by checksum rather than by size and modification time. It is slower than a plain copy, and it is the version to use when correctness matters more than speed. Run the same command a second time; if the copy is good, it transfers nothing and finishes quickly, which is itself a verification.

Note the trailing slash on the source path. With it, the contents of Project go into the destination Project. Without it, you get Project nested inside Project. This catches everyone at least once.

Which algorithm, and does it matter

shasum -a 256 is the sensible default. You may see md5 recommended in older guides. MD5 is fine for detecting accidental corruption, which is all we are doing here, and it is faster on large files:

md5 /path/to/file

It is not suitable where someone might deliberately construct a colliding file, but that is not the threat when you are checking whether a USB cable dropped a bit. Use MD5 for speed on very large media files, SHA-256 for anything you want a durable record of.

What a mismatch actually means

A failed comparison tells you the copy differs from the original. It does not tell you which one is wrong, and that is worth pausing on.

Re-copy the file and verify again. If the second copy matches the source, the first transfer glitched and you are done. If repeated copies produce different checksums each time, the source is being read unreliably, which points at the source drive or its connection rather than the file. If every copy matches each other but not the original checksum you recorded weeks ago, the original may have degraded in place.

Test the source read in isolation before concluding anything:

cp /path/to/source /dev/null

That reads the whole file and discards it. A clean run means the source can be read. An error moves you into the territory covered in error code -36.

When verification fails and the file matters

If a file no longer matches its original and there is no clean copy, the question becomes how much of it is usable. That depends on the format. Text and images degrade gracefully; a damaged region ruins part of the picture and the rest still opens. Video and archives often do not, because a single damaged region can break the index that everything else depends on.

Manatee reads what structure survives in a damaged video, audio file, PDF or Office document and writes a clean copy, always from a duplicate so the file you still have is not altered by the attempt. It is direct about outcomes rather than reporting success on a file that will not play. Why files get corrupted and what can actually be recovered is worth reading before you spend an evening on it, because some damage genuinely is terminal and knowing that early is useful.

A habit worth forming

For anything irreplaceable, write the checksum down when the file is created, not when you first suspect a problem. A manifest file stored alongside a photo archive or a video project costs nothing and means that in five years you can tell the difference between “this file was always like this” and “this file has degraded”. Without it, you are guessing.

Questions

Does the Finder verify copies itself? Not in a way it reports to you. It checks that the write operations returned success, which is not the same as reading the data back and comparing it.

Is Disk Utility’s Restore verification the same thing? Similar in spirit, for disk images. It checks the image against a recorded checksum. It does not verify individual files you copied by hand.

Why do two identical-looking files have different checksums? Because something differs, even if it is invisible. On a Mac the usual innocent explanation is extended attributes, but those are not part of the file’s data and do not affect shasum. If the checksums differ, the bytes differ.

How long does verifying a large file take? It is limited by read speed. A file that takes two minutes to copy takes roughly two minutes to checksum on each side, so budget about double the copy time for a full verify. rsync -avc on a second pass is the cheaper way to re-verify later.