# VerifiedCopy

> VerifiedCopy is a $4.99 macOS app that copies files and proves each copy is intact. Every chunk is written, flushed to the drive, read back, and its SHA-256 hash compared with the source. If a chunk doesn't match, only that chunk is rewritten and re-checked, so a bad block never means restarting the file or the copy. Made by independent developer Ting Tze Chuen.

This is the full-text companion of [/llms.txt](https://verifiedcopy.app/llms.txt). It contains the homepage and all three guides on https://verifiedcopy.app as Markdown, without navigation or footers.

Last updated: 2026-10-07

Contents:

1. [Homepage](https://verifiedcopy.app/)
2. [How to verify a file copy on Mac](https://verifiedcopy.app/verify-file-copy-mac/)
3. [exFAT file corruption on Mac](https://verifiedcopy.app/exfat-corruption-mac/)
4. [How to safely offload camera cards on a Mac](https://verifiedcopy.app/offload-camera-cards-mac/)

---

# Homepage

Source: https://verifiedcopy.app/

## Your photos made it. We checked.

Finder calls a copy done the moment the last byte is written. It never reads the file back. VerifiedCopy does: it writes each chunk, flushes it to the drive, reads it back, matches it against the original with SHA-256, and only then tells you it's OK.

- $4.99 on the Mac App Store, pay once, no subscription
- Try it free for 14 days
- macOS 14 Sonoma or later
- Works fully offline

## Three steps, for every single file

A copy isn't trusted just because it was written. It has to be read back from the drive and matched against the source.

1. **Copy.** Your files stream to one, two, or three drives at once, with progress for each file and the whole job. The source is read only once.
2. **Read it back** (Finder skips this). Each chunk is flushed to the drive with F_FULLFSYNC and then read back from the destination.
3. **Match.** Each chunk's SHA-256 hash is checked against the source. If one chunk is off, only that chunk is rewritten and checked again. No starting the file or the whole copy over.

## Here's what it looks like

Pick your files, watch them get checked, and see exactly what's healthy. No mystery progress bar that only tells you what macOS believes.

- Watch every file get checked: speed, time left, and a clear status for each file as it's copied and verified.
- Pick a source and up to three drives.
- See intact, corrupted, and repaired blocks.

## Why I made this

I kept copying videos to an exFAT drive, ejecting safely, and finding them corrupted on the TV.

macOS said the copy succeeded. Safe eject said the drive was safe. Neither actually reads the file back to confirm the bytes survived the trip. VerifiedCopy is the tool I wanted to exist: it copies, then reads the data back and tells you honestly whether the copy arrived intact.

— Ting Tze Chuen, maker of VerifiedCopy

## Six things it does well

Every feature is there to make sure your files arrive exactly as they left.

- **Copy & Verify.** Copy to one drive or several, read every chunk back, and confirm it matches. A bad chunk gets rewritten on the spot (up to 3 attempts by default, configurable 1 to 10), so you never restart the copy. A full-file SHA-256 pass runs afterwards by default.
- **Verify & Repair.** Scans an existing backup against a known-good source and rewrites only the damaged chunks, not the whole file, then re-verifies the repaired chunks. Big archives stay quick to fix when just a few sectors go bad. Scans can save a hash manifest (.verifiedcopy-manifest.json).
- **Integrity view.** A block map for any file. Intact, corrupted, and repaired chunks are easy to see at a glance.
- **Up to three drives at once.** One copy job, up to three destinations, with the source read once. A verified 3-2-1 backup across several drives in a single pass.
- **Offline, always.** No network access, no data collection, no accounts. It runs in Apple's macOS sandbox and only touches the files you pick.
- **Native and tiny.** A native Swift app, 1.8 MB on the Mac App Store. Works from the app window, Finder Services ("Copy with VerifiedCopy"), the Dock, Shortcuts, Spotlight, the menu bar, and a URL scheme.

Other options: auto-dated destination folders, a conflict pre-scan before anything is written, remembered destinations, eject after copy, and 1 to 4 parallel copies. Copy jobs can save a CSV or JSON report to each destination; the JSON report includes per-chunk SHA-256 hashes.

## Made for anyone with files they can't shoot again

### Photographers and videographers

Offload the card. Know every shot arrived. Offload camera cards knowing every RAW made it. Archive Final Cut Pro libraries with a report you can keep. Write to two drives at once and know both are clean. See [How to safely offload camera cards](https://verifiedcopy.app/offload-camera-cards-mac/).

### Sharing drives with Windows

Mac to exFAT to Windows? Check before you hand it over. Silent corruption on exFAT is a longstanding macOS issue. Finder will happily report a copy as successful even when bytes got mangled on the way, especially with large files or drives shared between Mac and Windows. VerifiedCopy reads every copy back from the exFAT drive and compares its SHA-256 hashes with the original, so you catch problems before you hand the drive off, not after someone opens it on Windows. See [Why exFAT corrupts files on Mac](https://verifiedcopy.app/exfat-corruption-mac/).

## VerifiedCopy vs Finder, cp, and rsync

Finder, `cp`, and a plain `rsync` all say "done" once the last byte is written. Only one of these reads the copy back and proves it matches.

| What it does | Finder | cp | rsync | VerifiedCopy |
|---|---|---|---|---|
| Reads the copy back after writing | No | No | Only if you re-run with -c | Yes, every chunk, by default |
| Checksum | None | None | Whole-file, on re-run | SHA-256 per 1–16 MB chunk, plus full-file pass |
| Pinpoints where a file is damaged | No | No | No | Yes, block map |
| Repairs only the damaged part | No | No | Re-copies the file | Rewrites only bad chunks |
| Several destinations in one pass | No | No | No | Up to three |
| Verification record | None | None | Terminal output | CSV/JSON report per destination; hash manifest from scans |
| Interface | Finder | Terminal | Terminal | Native Mac app |

## Specs

| Spec | Value |
|---|---|
| Hash | SHA-256, per chunk (1, 4, 8, or 16 MB; default 4 MB), plus full-file pass |
| Destinations | Up to three drives per copy job |
| Records | CSV or JSON report per destination (JSON includes per-chunk hashes); hash manifest from Verify & Repair scans |
| Works from | App window, Finder Services, Dock, Shortcuts, Spotlight, menu bar, URL scheme |
| Requirements | macOS 14.0 or later, Apple silicon or Intel |
| Price | $4.99 one-time, 14-day free trial |
| Privacy | Fully offline, sandboxed, no data collection |
| Size | 1.8 MB, native Swift |
| Current version | 1.2.0, released October 20, 2026 (first released April 13, 2026) |

## Questions people ask

### How does VerifiedCopy verify a copy?

Every file is copied in chunks of 1 to 16 MB (4 MB by default). Each chunk is written, flushed to the drive with F_FULLFSYNC, read back, and its SHA-256 hash compared against the source. If a chunk doesn't match, only that chunk is rewritten and checked again (up to 3 attempts by default), so one bad block never means restarting a big copy. A full-file SHA-256 pass runs afterwards by default.

### How do I verify that a file copy on my Mac is identical to the original?

Finder can't do it: it never reads the copy back. You can compare checksums by hand in Terminal (for example with `shasum -a 256` on both files), or use VerifiedCopy, which copies the files, reads every copy back from the destination, and compares SHA-256 hashes automatically for every file in the job. See [all the ways to do it](https://verifiedcopy.app/verify-file-copy-mac/).

### What's the difference between VerifiedCopy and Finder copy?

Finder copies files but doesn't verify them afterwards. A damaged sector, flaky cable, or failing drive can silently corrupt a file during the copy and you'd never know. VerifiedCopy reads every copy back and confirms it matches the original.

### Does VerifiedCopy work with external drives, SD cards, and network volumes?

Yes. VerifiedCopy works with any drive macOS can mount, including external SSDs, HDDs, USB sticks, SD cards, and network shares. You can copy to up to three destinations in one pass.

### Can VerifiedCopy help with exFAT corruption on Mac?

Yes. This is one of the most common reasons people install VerifiedCopy. Silent file corruption on exFAT drives is a longstanding macOS issue, especially with large files or drives shared between Mac and Windows. VerifiedCopy reads every copy back from the exFAT destination and compares its SHA-256 hashes against the source, so you know the file is intact before you hand the drive to a Windows machine.

### What is silent data corruption or bit rot?

Silent data corruption (sometimes called bit rot) is when a file's contents change without any error message, caused by aging storage, faulty cables, or stray cosmic rays flipping bits. You often only notice when you try to open the file years later.

### Is VerifiedCopy safe? Does it send data anywhere?

No, it doesn't send data anywhere. VerifiedCopy runs fully offline inside Apple's macOS sandbox. It has no network access, collects no data, and only accesses files you explicitly select.

### Can VerifiedCopy repair corrupted files?

Yes. Verify & Repair scans an existing backup against a known-good source and rewrites only the damaged chunks, not the entire file, then re-verifies them. That keeps repair fast, even for large archives where just a few sectors have gone bad.

### What file types and sizes does VerifiedCopy support?

Any file, any size. VerifiedCopy verifies raw bytes rather than looking at file formats, so it works equally well for photos, videos, databases, archives, or any other type of file.

### How is VerifiedCopy different from rsync or cp?

`cp` doesn't verify copies at all. rsync's `-c` flag compares checksums, but only if you re-run it yourself in Terminal, and it can't pinpoint or repair just the damaged region. VerifiedCopy is a native Mac app with SHA-256 verification on by default, a visual progress view, up to three destinations in one pass, and block-level repair.

### How much does VerifiedCopy cost?

VerifiedCopy costs $4.99 as a one-time purchase on the [Mac App Store](https://apps.apple.com/app/verifiedcopy/id6761552532). There is no subscription. A free 14-day trial is available as a [direct download](https://github.com/300apm/VerifiedCopy-releases/releases/download/v1.2.0/VerifiedCopy-1.2.0.dmg).

### What are VerifiedCopy's system requirements?

VerifiedCopy requires macOS 14.0 (Sonoma) or later and runs natively on Apple silicon and Intel Macs. It is a native Swift app, 1.8 MB on the Mac App Store.

---

# How to verify a file copy on Mac

Source: https://verifiedcopy.app/verify-file-copy-mac/
By Ting Tze Chuen · Updated October 7, 2026

Finder doesn't verify copies. To confirm a copy matches the original, compare checksums of both: run `shasum -a 256` on each file in Terminal, compare whole folders with `diff -rq`, or build a checksum list with `shasum -c`. An app like VerifiedCopy does the same thing automatically, reading every copy back and comparing SHA-256 hashes.

## Does Finder verify copied files?

No. When you drag files to another drive, Finder reports the copy as finished once the last write has been handed to the drive. It never reads the copied file back to check that the bytes on the destination match the source. If a cable drops out for a moment, a card reader stalls, or a sector on the destination is failing, the copy can be damaged and Finder will still show it as complete.

Most of the time copies are fine. The problem is that you can't tell which times they aren't until you open the file, which might be months later, after the original is gone.

## What "verifying a copy" actually means

Verifying means reading the copy back from the destination drive and comparing it with the original. The usual way is a checksum (also called a hash): a short fingerprint calculated from every byte of a file. If even one bit differs, the checksum changes completely. SHA-256 is the standard choice today; MD5 also catches accidental corruption but is considered obsolete for security uses.

Tip: right after a copy, macOS may still hold the file in memory. For a manual check, eject the destination drive and plug it back in first so the verification reads from the drive itself.

## Method 1: Compare one file with shasum

macOS includes `shasum`. Open Terminal and run it on both files:

```sh
shasum -a 256 ~/Movies/birthday.mov /Volumes/Backup/birthday.mov
```

You'll get two lines, each starting with a 64-character hash. If the hashes are identical, the files are identical. For a quick yes/no without hashes, `cmp file1 file2` prints nothing when the files match.

## Method 2: Compare two folders with diff

To check a whole folder, such as a camera card against its backup:

```sh
diff -rq /Volumes/CARD/DCIM /Volumes/Backup/DCIM
```

`diff` compares the contents of every file, byte for byte. No output means every file matches. Otherwise it lists files that differ or exist on only one side. It's thorough, but it leaves no record you can check again later.

## Method 3: Make a checksum list and check against it

This is the most useful manual method because the list doubles as a record. First, hash every file in the source folder:

```sh
cd /Volumes/CARD
find . -type f ! -name '.DS_Store' ! -name '._*' -print0 | sort -z \
  | xargs -0 shasum -a 256 > ~/card.sha256
```

Then check the copy against that list:

```sh
cd /Volumes/Backup/CARD
shasum -a 256 -c ~/card.sha256
```

Each file is reported as `OK` or `FAILED`. Keep the `.sha256` file next to the backup and you can re-run the check in a year to catch corruption that crept in later. The `find` filters skip Finder's `.DS_Store` and `._` metadata files, which often differ between drives without meaning anything is wrong.

## Method 4: rsync dry run with checksums

```sh
rsync -rcnv /Volumes/CARD/ /Volumes/Backup/CARD/
```

`-c` compares checksums instead of size and date, and `-n` makes it a dry run, so nothing is copied. Any file it lists is one rsync would re-send, meaning it differs or is missing. You have to remember to run it, and it can't tell you which part of a large file is damaged.

## Method 5: Use an app that verifies every copy

VerifiedCopy builds the check into the copy. It copies your files to up to three drives, flushes and reads back each 1 to 16 MB chunk, and compares SHA-256 hashes with the source. If a chunk is damaged, only that chunk is rewritten and re-checked, and a full-file SHA-256 pass runs afterwards by default. Each job can save a CSV or JSON report (the JSON includes per-chunk hashes) to each destination. For backups you already have, Verify & Repair scans them against the original, rewrites only the bad chunks, and can save a hash manifest.

## Which method should you use?

| Method | Checks contents | Whole folders | Reusable record | Repairs |
|---|---|---|---|---|
| Finder copy | No | n/a | No | No |
| `shasum` / `cmp` | Yes | One file at a time | No | No |
| `diff -rq` | Yes | Yes | No | No |
| `shasum -c` list | Yes | Yes | Yes | No |
| `rsync -rcn` | Yes | Yes | No | Re-copies whole files |
| VerifiedCopy | Yes, automatically | Yes, up to 3 destinations | CSV/JSON report; hash manifest from scans | Only damaged chunks |

For an occasional single file, `shasum` is enough. If you regularly copy photo libraries, footage, or archives, verification works best when it happens on every copy without you having to remember it.

## Frequently asked questions

### Does copying files in Finder check for errors?

Finder reports errors the drive itself reports, such as a disconnected drive or a full disk. It doesn't read the copy back, so silent corruption, where the drive accepts the data but stores it wrongly, goes unnoticed.

### Is MD5 good enough to verify a file copy?

For catching accidental corruption, MD5 works. SHA-256 is the modern default and avoids MD5's known weaknesses, so use it when you have a choice. On Mac, `shasum -a 256` and `md5` are both built in.

### How long does verifying a copy take?

Verification reads every byte of the copy again, so it takes roughly as long as reading the data once more from the slower of the two drives. On a fast SSD that's a small addition to the copy; on a USB 2.0 card reader it's noticeable.

### Can I verify files I copied a long time ago?

Yes, as long as you still have the originals or a checksum list made from them. Use `diff -rq` against the originals, or `shasum -a 256 -c` against a saved list. VerifiedCopy's Verify & Repair can also scan an old backup against a known-good source and fix only the damaged parts.

### Why do my checksums differ when the files look identical?

If the file sizes match but the hashes differ, the contents are different, even if the file still opens. Damaged video often plays until it reaches the bad section. Copy the file again from the original and check it again.

---

# exFAT file corruption on Mac: why it happens and how to prevent it

Source: https://verifiedcopy.app/exfat-corruption-mac/
By Ting Tze Chuen · Updated October 7, 2026

exFAT has no journal and doesn't checksum file contents, so an interrupted write or a bad transfer can leave a file damaged with no error message. On a Mac, the usual causes are unplugging without ejecting, unreliable cables and hubs, and moving drives between computers mid-write. Disk Utility's First Aid repairs the file system but not damaged files. To catch those, verify each copy against the original.

## A familiar story

VerifiedCopy exists because of exactly this problem. I kept copying videos to an exFAT drive on my Mac, ejecting it safely, and plugging it into the TV, only to find some of them corrupted. macOS said every copy succeeded. Nothing warned me. The only way to know was to read the files back and compare them with the originals, so I built a tool that does that.

## Why exFAT is more fragile than APFS

exFAT is popular because Macs and Windows PCs can both read and write it. That compatibility comes at a cost. According to Microsoft's exFAT specification:

- **There's no journal.** Journaled file systems record changes before making them so they can recover cleanly from a crash. exFAT only sets a "volume dirty" flag and relies on a repair tool to sort out inconsistencies afterwards.
- **There's one allocation table.** A standard exFAT volume keeps a single File Allocation Table. The second copy exists only in TexFAT, a variant used by Windows CE.
- **File contents aren't checksummed.** exFAT checksums its own structures (the boot region, directory entries, and the up-case table) but not the data inside your files. If a file's bytes are stored wrongly, the file system has no way to notice.

So if a write is interrupted, or bad data reaches the drive, exFAT will often report nothing wrong. You find out when the file won't open.

## Common causes of exFAT corruption on Mac

- **Unplugging without ejecting**, or the Mac sleeping or losing power with the drive mounted. Writes still in progress, or still in the cache, never make it to the drive.
- **Flaky connections.** Worn cables, unpowered USB hubs, and cheap adapters can drop out briefly during long transfers.
- **Moving the drive between Mac and Windows** without ejecting on both sides, so each system finds the volume marked dirty.
- **Failing or counterfeit flash.** Old USB sticks and fake-capacity SD cards can accept writes and then return different data.
- **Large files and long transfers**, which simply give the problems above more time to happen.

## Symptoms

- Videos that freeze, glitch, or stop playing partway through
- Photos with grey bands or blocks, or that won't open
- Files that show the right size but contain garbage, or show as zero bytes
- Windows offering to "Scan and fix" the drive when you plug it in
- The drive failing to mount, or mounting read-only

## How to repair an exFAT drive on Mac

Back up anything you can still read first. Then repair the file system:

1. Open Disk Utility and select the exFAT volume in the sidebar.
2. Click First Aid, then Run (see Apple's Disk Utility guide).
3. If it reports errors it couldn't fix, try again from Terminal with `diskutil repairVolume /Volumes/NAME`, or on a Windows PC with `chkdsk X: /f`.

Important: First Aid and chkdsk repair the file system's bookkeeping, not your files' contents. A video whose bytes were damaged in transit will still be damaged after a successful repair.

## How to fix damaged files

If you still have the originals, the fix is to copy the damaged files again and check the new copies. To find which files are damaged, compare the drive with the originals using `diff -rq` or checksums (see [how to verify a file copy on Mac](https://verifiedcopy.app/verify-file-copy-mac/)).

VerifiedCopy can do this in one pass: Verify & Repair scans the exFAT copy against the known-good originals, chunk by chunk, rewrites only the chunks that don't match, and re-verifies them. For a large video with a few bad sectors, that's much faster than copying everything again.

## How to prevent exFAT corruption

- **Always eject before unplugging**, on both Mac and Windows, and wait for the drive to disappear from the sidebar.
- **Connect directly to the Mac** for big transfers instead of through a hub, and replace cables that disconnect when bumped.
- **Format the drive on the Mac** in Disk Utility (exFAT, GUID Partition Map) if you see repeated problems after using it elsewhere.
- **Don't use exFAT if you don't need it.** If the drive only ever connects to Macs, use APFS.
- **Verify every copy.** This is the only step that catches problems the file system can't see. VerifiedCopy reads each copy back from the exFAT destination and compares SHA-256 hashes with the source before you hand the drive over.

## exFAT vs APFS vs Mac OS Extended vs NTFS

| Format | Mac | Windows | Crash protection | Best for |
|---|---|---|---|---|
| APFS | Read/write | No (without extra software) | Copy-on-write metadata | Mac-only drives and SSDs |
| Mac OS Extended | Read/write | No (without extra software) | Journaled | Older Macs, spinning backup disks |
| exFAT | Read/write | Read/write | None | Drives shared with Windows, cameras, TVs |
| NTFS | Read-only | Read/write | Journaled | Windows-only drives |
| FAT32 | Read/write | Read/write | None | Small drives; files under 4 GB only |

If a drive has to work with both Mac and Windows, exFAT is usually the only practical choice. That's fine, as long as you eject properly and verify what you copy.

## Frequently asked questions

### Is exFAT bad for Mac?

No, but it's less forgiving than APFS. exFAT has no journal and no checksums on file contents, so interrupted or bad writes are more likely to go unnoticed. It's the right choice for drives shared with Windows; use APFS for Mac-only drives.

### Why does Windows ask to scan and fix my exFAT drive?

Windows found the volume's dirty flag set, usually because the drive was unplugged from the Mac without ejecting or while a write was still in progress. Let it scan, then check that your important files still match their originals.

### Will First Aid fix my corrupted videos?

No. First Aid repairs the file system's structures so the drive mounts and files are listed correctly. It can't restore bytes inside a file that were damaged during the copy. Copy those files again from the originals and verify them.

### What are the ._ files on my exFAT drive?

They're AppleDouble files that macOS creates on non-Mac file systems to store extra metadata such as Finder tags. They aren't corruption. You can merge and remove them with `dot_clean /Volumes/NAME` in Terminal before giving the drive to a Windows user.

### How do I know if a file on exFAT is corrupted?

Compare it with the original. Run `shasum -a 256` on both files; if the hashes differ, the copy is damaged. To check every file on a drive at once, use `diff -rq` against the source folder, or an app like VerifiedCopy.

---

# How to safely offload camera cards on a Mac

Source: https://verifiedcopy.app/offload-camera-cards-mac/
By Ting Tze Chuen · Updated October 7, 2026

Copy the whole card to at least two drives, verify every copy against the card with checksums, and only format the card in the camera once both copies check out. Dragging files in Finder skips the verification step, so use an offload tool that checks each copy, or compare checksums yourself before wiping anything.

## Why a plain Finder drag isn't enough

Once you format a card, the only copies of those photos and clips are the ones on your drives. Finder copies files without ever reading them back, so a card reader that stalls for a moment or a drive with a weak sector can leave a damaged file that looks perfectly normal in the folder. Usually you only find out in the edit, after the card has been reused.

A safe offload adds two things: a second copy, and proof that both copies match the card.

## Step-by-step: a safe offload workflow

1. **Lock the card.** If it's an SD card, slide the write-protect switch so nothing on the Mac can modify it while you copy.
2. **Use a good reader, plugged in directly.** Avoid unpowered hubs and long adapter chains. Most card-reading errors come from the connection, not the card.
3. **Copy the whole card, not just the clips.** Many video cameras store metadata in folders next to the media files. Keep the folder structure intact, ideally in a folder named with the date and card number.
4. **Copy to two drives.** Following the 3-2-1 rule (three copies, two kinds of media, one off-site), the card plus two drives gets you most of the way there on the shoot day.
5. **Verify both copies.** Read each copy back and compare it with the card using checksums. See [how to verify a file copy on Mac](https://verifiedcopy.app/verify-file-copy-mac/) for the Terminal commands.
6. **Keep the record.** Save the checksum list or report next to the footage so you can check the backup again later.
7. **Eject, then format in camera.** Format the card in the camera that will use it next, rather than deleting files on the Mac.

## Doing it with VerifiedCopy

VerifiedCopy handles steps 3 to 7 in one pass:

- Drag the card in and pick up to three destination drives. The card is read once and each file is copied to all of them.
- Every copy is flushed to the drive, read back, and checked with SHA-256, chunk by chunk. If a chunk doesn't match, just that chunk is rewritten from the card and checked again, so a 50 GB card never has to be offloaded from the start.
- Optional auto-dated destination folders keep each offload separate, and a conflict pre-scan catches filename clashes before anything is written.
- Each job can save a CSV or JSON report to each destination; the JSON report includes per-chunk SHA-256 hashes.
- Turn on eject after copy to eject the drives when the job finishes.

It also remembers your destinations, and you can start an offload from Finder's Services menu ("Copy with VerifiedCopy"), the Dock, or the Shortcuts action.

## Other offload tools

Dedicated DIT applications such as ShotPut Pro, Hedge, and OffShoot are widely used on professional sets and add features like MHL reports for post-production handoff. VerifiedCopy is a lighter, general-purpose Mac utility: one-time $4.99, no account, fully offline, and useful for any files, not just camera cards. Pick whichever fits your workflow. What matters is that something verifies the copy before the card is formatted.

## Offload checklist

| Check | Why |
|---|---|
| Card locked | Nothing can modify the source mid-copy |
| Whole card copied | Keeps metadata and folder structure the camera's software expects |
| Two destination drives | One drive failing doesn't lose the shoot |
| Both copies verified | Proves each copy matches the card |
| Record saved | Lets you re-check the backup months later |
| Formatted in camera | Only after everything above passes |

## Frequently asked questions

### Should I delete photos from the card on my Mac?

It's better to format the card in the camera after you've verified your copies. Formatting in camera sets the card up exactly as that camera expects and avoids leftover files or a fragmented card.

### How many copies of a shoot should I make?

At least two copies on separate drives before you format the card, and ideally a third kept off-site later. That's the 3-2-1 backup rule: three copies, on two kinds of media, with one off-site.

### Do I need to verify copies to a fast SSD?

Yes. Verification protects against problems anywhere along the way, including the card, the reader, the cable, and the destination drive. A fast SSD makes verification quicker, but it doesn't remove the need for it.

### Does Lightroom or Photos verify imports?

Photo app imports generally copy files without reading them back to compare checksums. If your app doesn't explicitly say it verifies imports, offload and verify the card first, then import from the verified copy.

### How long does a verified offload take?

A verified copy reads the data twice, once to copy and once to check, so expect it to take longer than a plain copy. How much longer depends mostly on the speed of your card reader and the slowest destination drive.

---

# Finder error -36, -43 and -50 on Mac: what they mean and how to fix them

URL: https://verifiedcopy.app/finder-error-36-43-50-mac/

-36 is an I/O error, -43 means "file not found" and -50 means a request was rejected as invalid. When copying, they usually point to a flaky connection, a damaged file system, or leftover ._ metadata files on exFAT, SD cards and network drives. Relaunch Finder, swap the cable or reader, run dot_clean and Disk Utility First Aid, then retry in smaller batches or with rsync.

## Frequently asked questions

### Does error -36 mean my drive is dying?

Not necessarily. Error -36 only says a read or write failed. A loose cable, a tired card reader or a hub that can't supply enough power causes it as often as a failing drive. If the error follows the drive across different cables, ports and Macs, or First Aid reports errors it can't repair, treat the drive as suspect and copy everything off it.

### Is it safe to delete ._ files?

Usually, yes. A ._ file holds the Mac metadata for the file with the same name, such as Finder tags, so deleting it loses only that metadata, not the file's contents. Running dot_clean -n removes only the ._ files whose matching file no longer exists, which is the safest place to start.

### Why do I get error -50 copying to a NAS?

Error -50 means the destination rejected something about the request. Network shares are a common trigger because the server's file system may not accept a filename, character or piece of Mac metadata. Try renaming the file to plain letters and numbers, reconnecting to the share, or copying with rsync, which skips most Mac metadata by default.

### Will reformatting the drive fix these errors?

Reformatting fixes problems in the file system itself, such as damage that First Aid can't repair, and it erases everything on the drive. It won't fix a bad cable, a faulty reader or failing hardware. Rule those out first, and copy off anything you need before you erase.

### If the copy finished without an error, is the file definitely fine?

No. Finder only reports errors the drive reports. It doesn't read the copy back, so data that was written wrongly but without an error goes unnoticed. To be sure, compare checksums of the original and the copy, or use a tool that verifies every copy.

---

# How to tell if a file is corrupted on a Mac

URL: https://verifiedcopy.app/check-file-corrupted-mac/

Without the original, you can only check that a file decodes cleanly. Test archives with unzip -t or gzip -t, decode videos with ffmpeg -v error -i file -f null -, and convert images with sips. These catch most damage, but not all of it. The only proof a file is intact is a matching hash, such as shasum -a 256, against a known-good copy or a saved checksum list.

## Frequently asked questions

### Can a file be corrupted if it still opens?

Yes. A photo can open with a grey band at the bottom, and a video can play normally until it reaches the damaged section. Opening a file only proves its header is readable, not that every byte is correct.

### Does the file command detect corruption?

No. file only reads the first bytes to identify the format. A JPEG cut off halfway is still reported as JPEG image data with the right dimensions. Use a check that decodes the whole file instead.

### Is there a built-in way to check a video for corruption on Mac?

macOS doesn't include a command-line video checker. You can play the clip through in QuickTime Player and watch for glitches, or install ffmpeg with Homebrew and run ffmpeg -v error -i clip.mov -f null - to decode every frame and print any errors.

### Can I fix a corrupted file?

The reliable fix is to copy the file again from a good copy. Repair tools for specific formats can sometimes rescue part of a damaged video or archive, but they can't restore data that was never written correctly. If you still have the original, replace the damaged copy and verify it with a checksum.

### Does a clean ffmpeg check mean my video is perfect?

Not quite. It means every frame decoded without an error, which rules out most damage. A few wrong bytes inside a frame can still decode as a slightly wrong picture with no error. Only a matching SHA-256 hash against a known-good copy proves the file is identical.

---

# “Too large for the volume’s format” on Mac: how to copy files over 4 GB

URL: https://verifiedcopy.app/file-too-large-fat32-mac/

The drive is formatted as FAT32 (MS-DOS FAT), which can't store any single file larger than 4 GB minus one byte, no matter how much free space it has. To fix it, reformat the drive as exFAT if you also use it with Windows, or APFS if it's Mac-only. Reformatting erases the drive, so copy its files off first. If you can't reformat, split the file into pieces under 4 GB.

## Frequently asked questions

### Why does a 64 GB drive say a 5 GB file is too large?

Because the limit is per file, not per drive. A FAT32 drive can be nearly empty and still refuse any single file larger than 4,294,967,295 bytes. Lots of smaller files will fit until the drive is full.

### Can I convert FAT32 to exFAT without erasing the drive?

Not with the tools built into macOS. Disk Utility and diskutil change a drive's format by erasing it, so copy everything you want to keep to another drive first, reformat, then copy it back.

### What is the exact largest file FAT32 can store?

4,294,967,295 bytes, which is 4 GiB minus one byte. Finder counts 1 GB as a billion bytes, so it shows that size as about 4.29 GB. Anything Finder lists at 4.3 GB or more won't fit.

### Will an exFAT drive work with Windows, a TV or a camera?

Current versions of Windows and macOS can both read and write exFAT without extra software. TVs, car stereos, game consoles and older cameras vary, and some only read FAT32, so check the device's manual before reformatting a drive you use with it.

### Is it safe to split a large video file?

Yes, as long as you rejoin the pieces before using the file. The pieces on their own won't play. After rejoining, compare the result with the original using shasum -a 256 to confirm nothing was lost.

---

# Does APFS protect your files from bit rot?

URL: https://verifiedcopy.app/apfs-bit-rot-mac/

Only partly. APFS, the Mac's default file system, checksums its own metadata, but not the contents of your files. If a photo or video changes silently on disk, APFS won't notice, won't warn you, and can't repair it. To protect against bit rot on a Mac, keep SHA-256 checksums of important files, verify every copy when you make it, keep more than one copy, and re-check them periodically.

## Frequently asked questions

### Does APFS have data checksums?

No. APFS uses Fletcher 64 checksums on its metadata objects, such as the structures that track files and folders. The contents of your files are not checksummed, so APFS can't tell you if a photo or video has silently changed.

### Will Disk Utility First Aid find corrupted files?

Not reliably. Apple describes First Aid as checking the formatting and directory structure of a drive. It doesn't compare file contents with anything, so a file whose data has changed but whose metadata is intact looks healthy.

### Is bit rot more of a problem on SSDs or hard drives?

Both can return wrong data without reporting an error, because firmware, controllers and connections can fail in ways the drive's own error correction doesn't catch. Rather than trusting one kind of drive, keep checksums so you can detect corruption on any of them.

### Can I use ZFS on a Mac?

Not out of the box. macOS doesn't include ZFS or Btrfs. Third-party ports of OpenZFS exist, but they add kernel extensions and maintenance work, so most Mac users are better served by checksum lists and multiple verified copies.

### How often should I re-check my backups?

There's no official interval. A common habit is once or twice a year for archive drives, and whenever a drive has been moved, dropped or left unused for a long time. Re-checking also reads every file, which shows up failing sectors early.

---

# Do Time Machine and Carbon Copy Cloner verify your backups?

URL: https://verifiedcopy.app/does-time-machine-verify-backups/

Mostly not by default. Time Machine doesn't read back the files it copies to a disk plugged into your Mac, and its Verify Backups command only applies to network backups. Carbon Copy Cloner can verify, but you have to turn it on: Re-verify files that were copied checks each new copy, and Backup Health Check compares checksums of every file on both sides.

## Frequently asked questions

### Does Time Machine check backed-up files for corruption?

Not on a typical backup disk plugged into your Mac. Apple says Time Machine periodically verifies backups on network disks, and older HFS+ backups store checksums you can check with tmutil verifychecksums. For a modern APFS backup disk, there's no built-in way to check file contents.

### Why is Verify Backups greyed out or missing?

You have to hold the Option key while the Time Machine menu is open for it to appear. If it's still unavailable, your backup is most likely on a disk connected directly to your Mac rather than a network disk, where the command isn't designed to work.

### Does tmutil verifychecksums work on APFS backups?

Not usefully. The command runs and prints nothing, which normally means no problems were found, but Howard Oakley's testing found no recorded checksums in APFS backups for it to check. It's meaningful only for HFS+ backups made by OS X 10.11 or later.

### How often should I run Carbon Copy Cloner's Backup Health Check?

Bombich recommends limiting it to weekly or monthly, because it re-reads every file on both the source and the backup. CCC's popup menu next to the setting lets you choose the interval, or run it only on the next backup.

### Is VerifiedCopy a replacement for Time Machine?

No. VerifiedCopy doesn't schedule backups, keep version history, or back up your whole Mac. It's for one-off copies such as camera cards, project archives, or moving files to a new drive, where you want each copy checked as it's written. Keep running Time Machine or CCC alongside it.

---

# OffShoot vs ShotPut Pro vs VerifiedCopy: Mac offload tools compared

URL: https://verifiedcopy.app/offshoot-shotput-pro-verifiedcopy-comparison/

They're built for different jobs. OffShoot (formerly Hedge) and ShotPut Pro are professional offload apps for Mac and Windows, with xxHash checksums, ASC MHL and camera reports, from $169 one-time. Pomfort's Offload Manager is Mac-only with time-limited licenses. VerifiedCopy is a $4.99 Mac app that reads back every chunk with SHA-256 and repairs only damaged blocks, but has no MHL.

## Frequently asked questions

### Is OffShoot the same app as Hedge?

Yes. Hedge was renamed OffShoot. According to Hedge's documentation, Hedge licenses that were eligible for updates on October 1, 2023 automatically became OffShoot licenses, and older ones can be extended to get OffShoot.

### Do I need MHL files?

Only if someone downstream asks for them, such as a studio, streamer, post house or DIT workflow. For personal archives and most photo work, a checksum report or a saved checksum list gives you the same practical benefit: a record you can check the copy against later.

### Is xxHash better than MD5 or SHA-256 for verifying copies?

xxHash is a non-cryptographic hash designed for speed, which is why offload tools use it by default. MD5 and SHA-256 are cryptographic and slower to compute. For catching accidental corruption during a copy, any of them will flag a changed file. Pick the one your workflow or client expects.

### Does VerifiedCopy create MHL files or run on Windows?

No to both. VerifiedCopy is a Mac app for macOS 14 and later. Copy jobs can save CSV or JSON reports with SHA-256 hashes, but it does not write MHL files. If you need ASC MHL or Windows, OffShoot Pro or ShotPut Pro are the better fit.

### Can I try these offload tools before buying?

Yes. OffShoot has a fully functional 10-day trial, ShotPut Pro's demo allows 10 offloads within 30 days, Pomfort's Offload Manager has a free 10-day trial, and VerifiedCopy has a 14-day free trial download. Running a trial on your own cards and drives is the most reliable way to choose.

---

# About the author and contact

Ting Tze Chuen is an independent macOS developer and the maker of VerifiedCopy, which started after videos copied to an exFAT drive kept turning up corrupted even though macOS reported every copy as successful.

- Website: https://ting.rocks
- Email: hello@ting.rocks
- Mac App Store: https://apps.apple.com/app/verifiedcopy/id6761552532 ($4.99 one-time)
- 14-day free trial: https://github.com/300apm/VerifiedCopy-releases/releases/download/v1.2.0/VerifiedCopy-1.2.0.dmg
- Privacy policy: https://verifiedcopy.app/privacy-policy/