What the Orphan Scan Reports and Why It Does Not Auto-delete Findings

Orphan Scan deliberately reports unmatched QCUL-looking directories/tables instead of automatically deleting them because naming alone is not sufficient proof of safe ownership.

What qualifies as a finding

The scan looks for QCUL laboratory-directory conventions and run-prefixed database-table patterns that do not correspond to current owned run records.

Why automatic deletion is disabled

A stale database restore, manual copy, failed historical migration, or administrator-created object could resemble QCUL data. Deleting it solely from a prefix/path match could destroy evidence or unrelated data. Version 1.01.14 records findings for controlled review.

Safe follow-up

  1. Confirm no active/history run owns the object.
  2. Check timestamps/contents and related QCUL error/cleanup records.
  3. Back up anything uncertain.
  4. Only then remove the verified orphan using appropriate filesystem/database tools.

Scheduled-task verification

After changing or repairing What the Orphan Scan Reports and Why It Does Not Auto-delete Findings, verify the canonical task row in System → Scheduled Tasks: enabled/disabled state, Last Execution, Next Execution, and Last Exit Code. Registration alone does not prove the maintenance routine runs; Joomla Scheduler still needs Lazy Scheduler or server cron to trigger due work.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.