Verify a file handoff: SHA-256 manifests and an eight-byte exercise

01Unpack the exercise and separate answers from inputs

Download the locally generated exercise pack below the answer. These are fictional demonstration files. Unpack the outer ZIP with the operating system: it contains handoff-v1, handoff-v2, reference-v1.json and accepted-v1.zip. Keep the README, reference manifest and nested ZIP out of the folder you verify.

1. 1
   Agree that handoff-v1 is the accepted version. A real handoff needs an independent confirmation channel; making a fresh manifest from received files cannot prove they are the intended originals.
2. 2
   Open File checksums and use the folder picker for handoff-v1, retaining docs and data in relative paths. The current picker removes the outermost folder name.
3. 3
   Import reference-v1.json and calculate/verify. If the browser asks to confirm folder access, check the folder name and its two files before continuing.

02Pass v1, then deliberately fail v2

1. 1
   V1 should show two matches, with no missing or extra files. Check note’s SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Save the JSON manifest and CSV verification report.
2. 2
   Select handoff-v2 and compare against the same reference-v1.json. Note must fail for its extra LF, even if both versions look like abc. The CSV should still match.
3. 3
   If the newline is an approved change, confirm a new version before issuing a new manifest. Otherwise restore the accepted v1 and verify again. Do not edit the reference hash merely to remove a failure.
4. 4
   Inspect accepted-v1.zip with ZIP extraction: download individual entries or repackage selected ones. Use the operating system to unpack a folder onto disk. Verify that unpacked folder again, then open note and the CSV to inspect their displayed contents.

Two missing and two extra files suggest a different outer directory or relative path. A note-only mismatch calls for checking bytes, line endings and BOM, followed by encoding and actual content changes.

03Use eight bytes to understand a checksum manifest

An invented minimum delivery has two UTF-8 text files. docs/note.txt contains exactly abc with no trailing newline: 3 bytes. data/list.csv contains id, LF, 7, LF, written as id\n7\n: 5 bytes. The two contents total 8 bytes. This is not the ZIP size and does not include the manifest itself.

The complete SHA-256 of abc is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. If an editor adds a trailing newline, the file becomes 4 bytes and its digest changes even though it still visibly says abc. This nonsensitive sample distinguishes hashing actual file bytes from hashing a separate copy pasted into a text box.

04Why a renamed file can have matching bytes and still be missing

The current checksum comparison finds corresponding files by relative path, then compares size and SHA-256. Renaming docs/note.txt to docs/notes.txt leaves the original path missing and adds an unexpected path even if both contents are abc. That is a filename requirement mismatch, not a digest error. Restore the agreed path or agree the change and export a new manifest from the newly accepted file set.

Folder selection removes the outer folder name while keeping relative directories inside it. Selecting individual files generally supplies filenames alone, which can collide for same-named files from separate directories. Use folder selection when directory structure matters. Do not edit the reference manifest merely to fit whatever arrived: the reference must come from the accepted delivery version.

05Checking the ZIP differs from accepting its extracted files

Comparing the ZIP’s own digest checks whether its bytes match the reference ZIP. If that reference package already omitted the final PDF, an identical copy still omits it. Review required paths, formats and versions first, create a manifest of accepted content files, and then package them. After receipt, extract into a new location, compare those files with the content manifest and open important outputs in the intended application.

Keep the reference manifest separate from the inspected content set. If checksums.json is placed in a selected folder, it can appear as an extra file. Define whether it belongs to the checked set and avoid requiring a manifest to contain its own final digest. For revisions, retain old and new manifests and explain additions, removals and changes instead of reintroducing an obsolete file just to satisfy an old check.

06Optional tools for a different input or next step

• Check delivery requirements: Set required items and limits, inspect missing, duplicate or empty files, then export a manifest for the reviewed set.
• Verify file integrity: Compute SHA-256 for the actual delivery files and compare against a trusted manifest after extraction or transfer; hashes do not certify correctness of the content.
• Organize a staging folder: Preview batch names and duplicate choices before exporting, checking that distinct revisions are not removed merely because names resemble each other.
• Compare delivery versions: Choose baseline and current folders or ZIP files, inspect added, removed and changed entries, and review previews where available.
• Check files before upload: Enter the actual destination’s size and pixel rules, review proposed image repairs and rerun the check on the final outputs.
• Create a ZIP archive: Package only the accepted staging set and retain its filenames and directory structure in the manifest.
• Inspect and extract a ZIP: Review entry names and counts, extract to a known location and open representative files; do not execute unfamiliar contents.
• Transfer a reviewed copy: Pair the intended devices, check the service and expiry information shown in the interface, and verify the received file rather than assuming pairing confirms delivery.
• Reuse a processing recipe: Inspect the imported chain and test a small batch with changed input sizes or columns before rerunning it on a new delivery.

07Accept the handoff at three different levels

The Library of Congress describes ZIP as a file package; inspect its contents separately from the archive’s outer filename.

For generated table groups, reconcile the ZIP manifest with expected groups. Size rules can include pixels and aspect ratio as well as bytes.