Ino S3 Verify File

Uploads fail. Network blips, wrong bucket, silently truncated objects - and in an automated pipeline, a failed upload is exactly the kind of thing you want to catch, not discover three batches later. Ino S3 Verify File is the pack's answer to "did it make it, and is it the same file?" It compares a local file against an object in S3 and reports existence, size, and optionally checksums - a proper integrity gate for pipelines that ship results to object storage.

It's part of ComfyUI Ino Nodes (nobandegani/ComfyUI-InoNodes), the 125+-node V3-schema pack, and one of its 16 S3 helpers. It's the grown-up counterpart to the upload nodes: upload, then verify, then mark the job done.

How it works

Inputs:

• enabled - the pack-wide toggle.
• s3_key - the object key in the bucket to compare against.
• parent_folder / folder / filename - locate the local file, using the same unified file-interface as the rest of the pack (dropdown for input/output/temp, plus subfolder and filename).
• s3_config - optional; config string or env vars.
• use_md5 and use_sha256 - the two optional integrity checks. Both default off; turn on the one you want (or both) for content-level verification rather than just existence and size.

The output list is almost comically thorough: success, message, rel_path, abs_path, then exists_remote (is it there at all?), sizes_match, verify_method (what you actually compared - e.g. size, md5, sha256), local_size, remote_size, etag, md5_match, and sha256_match. For a beginner that's a lot of sockets, but you'll mostly care about two: success and exists_remote.

When you'd use it

The textbook pattern is the tail of an upload pipeline: Ino S3 Upload Image pushes the file, then Ino S3 Verify File checks it, and your workflow only marks the job complete if success comes back True. The etag output is also handy if you're logging or auditing what actually got stored - S3's ETag is usually an MD5 of the object, so it doubles as a lightweight fingerprint.

Common issues

• Hash checks are opt-in. With both off, you're only verifying existence and size - good for a quick check, not for proving content integrity. Turn on use_sha256 if the bytes must match exactly.
• success vs exists_remote. success reflects whether the verification ran without errors; exists_remote tells you whether the object is actually there. An object that exists but has wrong size should read as success: True but sizes_match: False. Don't wire the wrong output into your gate.

Installing it

ComfyUI Ino Nodes installs like any custom node pack:

• ComfyUI Manager (easiest): search for "ComfyUI Ino Nodes", install, restart.
• Manual:

  cd ComfyUI/custom_nodes
  git clone https://github.com/nobandegani/ComfyUI-InoNodes.git
  cd ComfyUI-InoNodes
  pip install -r requirements.txt

  Then restart ComfyUI.

Requires inopyutils and a current ComfyUI. It's a niche pack with near-zero community footprint, but for a "trust but verify" step at the end of an S3 pipeline, this node is exactly the safety net you want.