Guide
How to verify a file transfer with checksums.
A transfer that “finished” isn’t the same as a transfer that arrived intact. Here is how editors can prove every file matches, with or without Bundvera.
Why size and date aren’t enough
- Same size, different content. Damage from a failing drive, an interrupted copy or a tool that rewrote a file can leave the size unchanged.
- Dates change on copy. Many copy and sync tools set new modification dates, so dates can’t tell you whether content changed.
- Missing files don’t announce themselves. Comparing folder totals rarely shows that one clip out of hundreds is absent.
What a SHA-256 checksum is
A checksum, or fingerprint, is a short value computed from every byte of a file. SHA-256 produces 64 hexadecimal characters. Change a single byte and the fingerprint changes completely. If the sender’s and the recipient’s fingerprints match, the files are identical.
Verifying by hand
Both macOS and Windows include tools to compute SHA-256 fingerprints.
One file on macOS (Terminal)
shasum -a 256 "A001_C001.MOV"A whole folder on macOS
On the sender’s side, from inside the delivery folder:
find . -type f ! -name checksums.txt -print0 | sort -z | xargs -0 shasum -a 256 > checksums.txtOn the recipient’s side, from inside the received folder:
shasum -a 256 -c checksums.txtOne file on Windows (PowerShell)
Get-FileHash "A001_C001.MOV" -Algorithm SHA256This works, but it leaves you comparing long lists, and it says nothing about media the project uses that was never in the folder.
Verifying with Bundvera
- The sender runs Deep Verification. Bundvera fingerprints every file with SHA-256 and saves a manifest,
<name>.bundvera-manifest.json, with paths relative to the delivery folder. - The folder and the manifest travel by any route: a drive, a cloud folder or a transfer service.
- The recipient opens the manifest in Bundvera, for free, and picks the received folder.
- Bundvera recomputes every fingerprint and names each file that is missing, modified, unexpected or renamed only by capitalisation.
Manifests, MHL and transfer services
Media hash lists in the ASC MHL format are a standard in camera-to-post workflows, supported by offload tools such as Hedge OffShoot and Pomfort Silverstack. Bundvera’s manifest is its own documented JSON format; Bundvera doesn’t read or write ASC MHL today.
Transfer services may check their own transfers. A Bundvera manifest is independent of the route: the recipient can verify the folder no matter how it travelled, or after it has been copied again.
Limits worth knowing
- A manifest isn’t digitally signed. Its integrity digest detects damage and casual edits, not a determined forger. Send it through a channel you trust.
- Matching fingerprints prove the files are identical, not that the project opens. Open it to confirm.
Questions
Why SHA-256 and not MD5 or xxHash?
SHA-256 is a cryptographic hash: finding two different files with the same SHA-256 fingerprint isn’t practically possible, by accident or on purpose. MD5 is no longer considered collision-resistant. xxHash is much faster and widely used in media offload workflows, but it isn’t designed to resist deliberate manipulation. Bundvera uses SHA-256 for every file.
Isn’t checking the file size enough?
No. A file can be damaged or altered without changing its size, and many transfer tools preserve sizes even when a copy is incomplete in other ways. Only reading every byte detects those changes.
Can I verify without Bundvera?
Yes. The commands on this page compute the same SHA-256 fingerprints with tools built into macOS and Windows. Bundvera adds the project-aware checks, the manifest, the comparison and a readable result.