How QCSB Protects an Item Before Delete

This article explains the verified protected-copy step that must succeed before a destructive delete is allowed and what happens when the protection destination is unavailable.

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.

Delete safety sequence

  1. The current user selects an item and QCSB confirms delete permission for that Workspace/location/item.
  2. Before provider deletion, QCSB creates a protected copy in the configured private recovery storage and verifies that copy.
  3. Only after protection succeeds does QCSB remove the provider item.
  4. A Recovery record preserves the original context and retain-until state for later Max/All Access management.
  5. If the protected copy cannot be created/verified, the delete is blocked instead of proceeding without safety protection.

Important limits and mistakes to avoid

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

Troubleshooting

  • If a file action fails, retry with one small test item and read Transfer Details or the operation toast before changing global settings.

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.