Card Offloader

The method

How verification works

Almost every offload tool verifies. The interesting question is not whether a tool checks the copy, but what it actually reads when it does.

Rule six of this product is that the verification method is documented publicly, because a checksum a third party can reproduce is worth more than ten reviews. This page is that documentation.

How far each kind of check actually reaches The data passes through the card, the reader and cable, the operating system's page cache, the drive's own write cache, and finally the medium. Comparing file counts checks nothing beyond the file system. Hashing what was written reaches only the operating system's cache. Reading the file back with the cache bypassed, after flushing the device, is the only check that reaches the medium. Where your bytes travel, and where each check stops Card source Reader, cable can corrupt OS page cache in memory Drive cache volatile The medium what survives Compare file count or folder size stops at the file system — a corrupt file has the right size Hash what was written, without reading back may compare memory with memory Flush the device, then read back with the cache bypassed the only one that reaches the medium — and the only one that costs real time
This is the whole argument. Every tool in this category verifies; what separates them is how far along this chain the verification actually travels.

One read of the card, many writes

The card is the slowest device in the chain and the one with a finite life. Reading it once per destination is the mistake that makes an offloader slow and wears out your media for no reason.

Card Offloader reads each file from the card exactly once. The bytes are hashed as they stream past and written to every destination in parallel. This is enforced by a test in the engine, not by good intentions: at the end of a job the counter of bytes read from the source must equal the total size of the scan, exactly, no matter how many destinations were selected.

1×reads of the card, whatever the number of destinations
1.75×time from one destination to three, while data written and re-read grows 3×

Measured 22 August 2026 on a real USB stick with destinations on internal SSD. Local hardware: this measures the engine, not a real-world workflow.

Going from one destination to three multiplies data by three but time by only 1.75 Two bars. Data written and re-read grows three times. Elapsed time grows 1.75 times, because the card is still read only once. Going from one destination to three Data written and read back 3× Time it actually takes 1.75× Because the card is still read exactly once. The extra cost is writing and verifying, which is the cheap half.
A third copy does not cost a third more time. Measured 22/08/26, local destinations. A network destination would not scale like this.

Then every device is flushed

When a write returns, the data is very often still sitting in the drive's own volatile cache. The operating system believes the file is written. The drive has not necessarily committed anything to the medium yet.

So before checking anything, Card Offloader issues F_FULLFSYNC to every destination device — the macOS request that asks the drive to actually commit its cache, rather than merely acknowledge it. Only after that does verification start.

And every file is read back, with the cache bypassed

A file that was just written is also likely to be in the operating system's page cache. Read it back straight away and you may never touch the disk at all: you compare memory with memory, get a match, and report a verified copy. The verification is fast, and it proves nothing about the drive.

Card Offloader reads each file back from the destination with F_NOCACHE, which forces the read to come from the device, and compares the hash with the one computed from the card.

Verifying immediately took 3.8 seconds; flushing first and re-reading took 13.1 seconds Bar chart comparing two verification strategies on the same 1,261 files. Verifying immediately after writing: 3.8 seconds. Flushing every device and then re-reading with the OS cache bypassed: 13.1 seconds. Same 1,261 files, two verification strategies Verify immediately after writing 3.8 s may never touch the disk Flush every device, then read back with the cache bypassed 13.1 s the 9.3 s difference is the reads that were not reaching the medium before
Slower is the correct answer here. The fast number was measuring the operating system's cache, not the drive. Measured 22/08/26 on local hardware; this compares two strategies against each other, not our software against anyone else's.

What that costs, measured

On the same 1,261 files, verifying immediately after writing took 3.8 s. Flushing every device first and then re-reading with the cache bypassed took 13.1 s.

Those nine extra seconds are the reads that were not reaching the medium before. Slower is the correct answer here: the fast number was measuring the wrong thing.

Both figures measured on the same file set on local hardware. They compare two verification strategies against each other, not our software against anyone else's.

This is not unique to us

It would be convenient to claim that nobody else does this. It would also be false, and easy to disprove. lastcard and Stow read files back off the destination, and MasterCopy: Verified Offload on the Mac App Store states plainly that each file is re-read from disk with the OS cache bypassed (all checked 24/08/26).

What we can say is narrower: we have written down exactly what we do, published the numbers it costs, and had our output validated by software that is not ours. That is a claim you can check rather than one you have to accept.

Which algorithm, and why it barely matters

The default is xxHash64: fast enough that the card, not the CPU, remains the bottleneck, and a first-class citizen in the ASC MHL specification, so nothing is lost in the report. Other algorithms are available.

The choice of hash function is the least interesting decision in verified copying. ShotPut Pro offers nine algorithms, OffShoot four, OWC Copy That five. A wider menu does not make a copy safer — when and what you read back does.

A failure is a failure

If one file cannot be verified, the job has failed and the report says so in red. The destination folder is created carrying the name !!! INCOMPLETE - DO NOT USE AS BACKUP !!! and sheds it only when every file has been verified — which means the state survives a crash, a power cut, or a Mac that goes to sleep at the wrong moment. Come back the next morning and the folder name still tells you where you stand.

Backup SSD
!!! INCOMPLETE - DO NOT USE AS BACKUP !!! 2026-08-24 Shoot A
2026-08-23 Shoot B
The folder on top is still being written, or the job failed. The one below passed: every file was read back from the disk and matched. The state is in the folder name, not in an app that may no longer be running — so it survives a crash, a power cut, and coming back the next morning.

Verification is never a paid feature

Read-back verification is in the free tier, in full, for every file, and it will stay there. It is not a Pro upsell and it is not a setting you can accidentally turn off to go faster.

This is deliberate and it is not generosity: a verification you have to pay for is a verification the vendor is willing to let you skip. What Pro adds is destinations, reports and queueing — never the guarantee that the copy is good.