How QCSB Protects an Existing Destination Before Replace or Overwrite

This article explains why Replace safely first preserves the item that would be overwritten, preventing conflict resolution from silently destroying the prior destination state.

What you need to know

  • Basic includes Local storage and the first active Workspace. Pro adds FTP/SFTP, multiple Workspaces, advanced permissions, and background continuation. Max/All Access adds Google Drive, OneDrive, Private Connections, Recovery Vault management, and bulk operations.
  • A plan gate decides whether a feature exists at the current Effective tier. Joomla access and QCSB permission rules separately decide whether a particular user may use that feature.
  • 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.

Replace-safely sequence

  1. QCSB detects that the intended destination name already exists and the chosen conflict policy is Replace safely.
  2. It creates and verifies Recovery protection for the existing destination object before altering it.
  3. If protection fails, replacement is blocked and the existing destination remains the authoritative object.
  4. When protection succeeds, QCSB writes/verifies the incoming destination content.
  5. The protected previous destination remains governed by Recovery retention/purge rules rather than disappearing silently.

Important limits and mistakes to avoid

  • Do not bypass failed recovery protection to force a destructive action. The block is intentional safety behavior.

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.