This problem was first sent to CarbonCopyCloner tech support by this message:
CarbonCopyCloner could not back up all my files because my destination backup disk was crowded. I ran TechTool Pro 13 Volume Optimization to consolidate free space on the destination disk. This optimization/consolidation process took a long time, so I left it running overnight. During the night a scheduled CCC backup occurred. The next morning the CCC backup had completed successfully, TTP was not running, and the TTP optimization was only partially completed. I launched TTP and attempted to restart the Volume Optimization, but could not because the destination disk could not be mounted. Disk Warrior 5.2 found several errors and repaired the disk. Unfortunately I did not save the repair record.
It seems to me that CCC is proceeding with its backup task even thought the destination disk is unmounted and in use. Something, somewhere, somehow, should prevent this apparent conflict between CCC and TTP.
Please investigate.
CCC tech support replied:
Hi Tom,
It seems to me that CCC is proceeding with its backup task even thought the destination disk is unmounted and in use.
That's correct, CCC will mount the source and destination volumes if they're not mounted when the task starts. That functionality is documented here:
Mounting the source or destination volume before a backup task begins
CCC can't know if some other application is using a particular volume, though. If an unmounted volume should not be mounted, e.g. because some other software is doing something to the volume that requires that is remains unmounted, then the onus is on that software to dissent a mount request via DiskArbitration. CCC won't (and can't) force a volume to be mounted if some other application dissents the mount requests.
Something, somewhere, somehow, should prevent this apparent conflict between CCC and TTP.
I agree. I recommend that you reach out to TTP and ask that they dissent the volume mount request if that's the correct behavior for whatever task you were performing on the volume. I would expect the developer of a disk utility to be well versed in the DiskArbitration APIs, but for reference, that functionality is documented here:
developer.apple.com/documentation/diskar...skmountapprovalcallb
So now I repeat my request, this time to you at Micromat: Please investigate.
Tom
CarbonCopyCloner could not back up all my files because my destination backup disk was crowded. I ran TechTool Pro 13 Volume Optimization to consolidate free space on the destination disk. This optimization/consolidation process took a long time, so I left it running overnight. During the night a scheduled CCC backup occurred. The next morning the CCC backup had completed successfully, TTP was not running, and the TTP optimization was only partially completed. I launched TTP and attempted to restart the Volume Optimization, but could not because the destination disk could not be mounted. Disk Warrior 5.2 found several errors and repaired the disk. Unfortunately I did not save the repair record.
It seems to me that CCC is proceeding with its backup task even thought the destination disk is unmounted and in use. Something, somewhere, somehow, should prevent this apparent conflict between CCC and TTP.
Please investigate.
CCC tech support replied:
Hi Tom,
It seems to me that CCC is proceeding with its backup task even thought the destination disk is unmounted and in use.
That's correct, CCC will mount the source and destination volumes if they're not mounted when the task starts. That functionality is documented here:
Mounting the source or destination volume before a backup task begins
CCC can't know if some other application is using a particular volume, though. If an unmounted volume should not be mounted, e.g. because some other software is doing something to the volume that requires that is remains unmounted, then the onus is on that software to dissent a mount request via DiskArbitration. CCC won't (and can't) force a volume to be mounted if some other application dissents the mount requests.
Something, somewhere, somehow, should prevent this apparent conflict between CCC and TTP.
I agree. I recommend that you reach out to TTP and ask that they dissent the volume mount request if that's the correct behavior for whatever task you were performing on the volume. I would expect the developer of a disk utility to be well versed in the DiskArbitration APIs, but for reference, that functionality is documented here:
developer.apple.com/documentation/diskar...skmountapprovalcallb
So now I repeat my request, this time to you at Micromat: Please investigate.
Tom