A file that copies to an external drive and arrives broken

A file plays perfectly from your internal drive. You copy it to an external disk, the Finder reports success, and the copy will not open. The size looks right. Copy it back and it is still broken.

This is a genuinely different problem from a file that fails to copy at all, because nothing reported an error. Something wrote bad data and told the system it had gone well. There are four realistic causes, and they are distinguishable.

First, confirm the file really is damaged

Before investigating the drive, establish that the copy differs from the original. Compare checksums:

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

Two different strings confirm the copy is not identical. If the strings match and the file still will not open from the external drive, the file is fine and something else is wrong, most likely the app reading it, or a permissions problem on the volume. That is a much easier situation, covered in when the Mac says an item is in use.

The full method, including verifying folders at once, is in verifying a file arrived intact.

Cause one: the four gigabyte wall

Check the drive’s format first, because this cause is instant to confirm and accounts for a great many broken video files.

Get Info on the drive. If Format reads MS-DOS (FAT32), no single file larger than 4 GB can exist on it. What happens next depends on the tool doing the copying: some refuse cleanly, and some write the first 4 GB and stop, producing exactly the symptom described here.

A video truncated at 4 GB is usually unplayable, and for a specific reason. In an MP4 or MOV file the actual picture data lives in an mdat block, and the index describing where every frame sits lives in a moov block. Recording tools typically write moov last, because the index cannot be finished until the recording is. Inspecting a normal file shows the order plainly:

ftyp (32 bytes) → free (8 bytes) → mdat (23,481,548 bytes) → moov (33,133 bytes)

Truncate that file anywhere before the end and you lose moov. The player then has all the frames and no map, which is why a half-copied video shows zero duration or refuses to open while clearly containing gigabytes of data.

The fix for the drive is to reformat it as exFAT, which has no practical file size limit and is readable by both macOS and Windows. Reformatting erases the drive, so move everything off first.

Cause two: the enclosure, not the disk

USB enclosures and adapters are the least reliable link in most setups, and a marginal one corrupts data without reporting anything. Cheap SATA-to-USB bridges are particularly prone to it under sustained writes, when they heat up.

Test by changing one variable at a time. Copy the same file using a different cable. Then a different port. Then, if you can, the same drive in a different enclosure. If the corruption follows the enclosure rather than the disk, you have your answer, and no amount of disk repair will help.

Bus-powered drives add a second failure mode: insufficient power. A spinning drive drawing more current than the port supplies will misbehave under load, typically part-way through a large write. If the drive has an optional power adapter, use it. If it is running through a hub, connect it directly to the Mac instead.

Cause three: the drive is failing

Check the disk’s own health report:

diskutil list
diskutil info disk2 | grep -i smart

Substitute the correct identifier from diskutil list. Verified means the drive is not reporting hardware failure. Failing means copy everything off immediately, starting with what is irreplaceable, and stop using it.

Then run First Aid in Disk Utility against the volume. It checks and repairs file system structures, which is a different question from whether the physical medium is sound, and both matter.

Be aware that SMART reporting over USB is unreliable; many bridges do not pass it through at all, which is why Not Supported is a common answer rather than a worrying one.

Cause four: the copy was interrupted invisibly

A drive that briefly disconnects and reconnects during a copy can leave a file that looks complete. Sleep is the usual trigger: the Mac idles, the drive spins down or the bus resets, and a long copy is left half-written.

Prevent it for the duration of a large transfer:

caffeinate -i rsync -avP --partial ~/Movies/ /Volumes/External/Movies/

caffeinate -i stops the Mac idle-sleeping while the command it wraps is running, and exits when the copy does. rsync -avP --partial resumes rather than restarting if something does go wrong, and reports a real error rather than closing a dialog.

You can also check the system log afterwards to see whether the drive dropped:

log show --last 1h --predicate 'eventMessage CONTAINS "USB"' | grep -i "disconnect\|reset" | head

Recovering what is on the external drive now

If the good original still exists, delete the bad copy, fix the underlying cause, and copy again with verification. That is always the better outcome.

If the external copy is now the only copy, the question is how much survives. For video, audio, PDFs and Office documents, Manatee reads whatever structure is intact and writes a clean copy, working from a duplicate so the damaged file stays exactly as it is. A video missing its moov index can often be rebuilt when the frame data is present, which is precisely the truncation case above. A file whose middle is full of zeroes because the enclosure wrote garbage is a harder problem, and it will tell you that rather than producing a file that still will not play. What can actually be recovered is the honest overview.

Questions

The file size matches exactly. How can it be damaged? Size is recorded in the file system, not derived from the content. A write that put the wrong bytes in the right number of blocks produces a file of correct size and wrong content. This is why checksums exist.

Should I use exFAT or APFS for an external drive? APFS if the drive is only ever used with Macs; it is the native format and the most reliable choice. exFAT if the drive must also work with Windows. Avoid FAT32 for anything involving video.

Does ejecting properly actually matter? Yes. macOS buffers writes, and ejecting flushes them. Pulling a drive without ejecting can leave recently written files incomplete even though the Finder showed the copy as finished minutes earlier.

Is a corrupted file on the drive a sign the whole drive is bad? Not necessarily, but treat it as a warning. Run First Aid, check SMART, and verify a few other large files with checksums. One bad file after a known interruption is explicable; several bad files with no obvious cause means back the drive up and replace it.