How QCSB Verifies a Transfer Before Finalizing It

This article explains destination existence/size verification and SHA-256 checking for files where applicable, and why destructive move source removal waits until destination verification succeeds.

What you need to know

• QCSB uses durable jobs but follows an immediate-first model: the request attempts ordinary work immediately, and only unfinished work remains for continuation.
• Pro/Max/All Access can use the 5-minute Transfer Continuation task. The worker rechecks the original user’s current authority before contacting a provider.

Verification sequence

1. QCSB writes/copies the destination through the selected provider service.
2. It confirms the expected destination object exists and compares the size where that check is meaningful.
3. For file transfers where the implementation can perform a content digest check, QCSB uses SHA-256 verification rather than treating a successful write call alone as proof.
4. Only after destination verification succeeds may a destructive Move proceed to source removal.
5. If verification fails, QCSB keeps the job/item in a non-success state and does not pretend the transfer completed safely.

Why this matters for Move

A Move is intentionally treated as copy/verify/protect/remove rather than a blind source deletion. The destination must be proven first, and the source is Recovery-protected before it is removed.

Verify the result

• The durable job reaches the expected terminal state: completed, completed with warnings, failed, or cancelled.
• Successful items remain successful; failed/retried items report their own sanitized outcome.
• For a Move, the source is removed only after the destination is verified and the source has required Recovery protection.

Community Discussion

For practical QCSB workflows and discussion with other Joomla site owners, visit the QC Storage Bridge Community. For private support, bug reports, account-specific entitlement issues, or feature requests, use the QuantaCade support system.