Understand QCSB Name Conflicts and Safe Destination Naming
This article explains how QCSB avoids unintended replacement, provider naming restrictions, and why conflict resolution is handled before destructive changes are finalized.
What you need to know
- Copy/Move authorization is directional: QCSB checks the source-side permission and the destination-side permission independently.
- Move is destructive only after the destination has been written and verified; the source is Recovery-protected before removal.
Conflict outcomes
| Case | Behavior |
|---|---|
| Preserve both | QCSB keeps the existing destination and chooses a unique safe destination name for the incoming item. |
| Replace safely | QCSB first creates/verifies Recovery protection for the existing destination, then replaces it. If protection fails, replacement is blocked. |
| Restore conflict | Recovery restore preserves both when the requested destination name already exists rather than silently overwriting the current item. |
Why provider naming still matters
QCSB normalizes/sanitizes names through provider-specific services, but the destination provider can still reject characters, reserved names, or constraints it does not support. A conflict policy solves an existing-name collision; it does not make an otherwise invalid provider name valid.
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.