Everytime something is cancelled by clicking in the little box of the activity window, it takes ages to actually do it.
The compact stage actually does not seem to be cancelable at all. Initially the box seems to accept clicks, but now it does not anymore and it's been running for 4:15...

If shutting down now breaks something, give me the choice: "stop immediately and loose 6 months of backup or close properly within the next hour or so?".

Now having this choice worries me because it means a HW failure would lead to a destroyed archive. The system should be resilient to that sort of abrupt failures. So why can't it do that by itself when I click the cancel button?

I would like "cancel" to be more reactive. Having to "force quit" is harder.

Fred

Frederic Thomas wrote:Every time something is cancelled by clicking in the little box of the activity window, it takes ages to actually do it.
The compact stage actually does not seem to be cancelable at all.

The only action that can't be canceled is a Merge. That's because the merge is deleting the directory structure of several layers and replacing it with a new layer. It's sort of an all or nothing proposition.

The Compact action is actually the most easily canceled action, with this caveat: If the compact has recovered a lot of space, that space must be overwritten by zeros to maintain the integrity of the archive. If, when you click on the cancel button the status changed to "Erasing free space", then the action has received the cancel request and is cleaning up. If it doesn't, then that's a bug I'd like to know about.

Initially the box seems to accept clicks, but now it does not anymore and it's been running for 4:15...

Once a cancel request has been accepted, the button disables itself. This indicates that the cancel request was received and reflects that fact that you can't cancel an action that has already been canceled.

How much space has the compact recovered and how fast is the drive? If your backup archive is on a USB port or network volume, things that take seconds to complete on a local drive might take minutes.

Now having this choice worries me because it means a HW failure would lead to a destroyed archive. The system should be resilient to that sort of abrupt failures.

QRecall archives are extremely resilient and specifically designed to avoid data loss even in the case of power failure or kernel panics. But one of the cornerstones of this design is that every single bit of an archive file is accounted for and is internally consisitent, which is why the compact must erase any "garbage" left over before it can close the archive.

If the QRecall action/process crashes or is interrupted for any reason, the repair command will be able to recover all of the successfully written data.

QRecall processes also interpret BSD kill signals as a cancel requests, so it's safe to shut down your system without first stopping a QRecall action. As the system shuts down, each running QRecall process will be cleanly canceled, finish up its work, and properly close its archive.

So why can't it do that by itself when I click the cancel button?

A QRecall archive that has not been properly closed cannot be used again until you perform a repair. Repairing an archive is an exacting and time consuming process, which is best avoided.

James Bucanek wrote:Repairing an archive is an exacting and time consuming process, which is best avoided.

All I am suggesting is to let the user take this decision. I am suggesting an option to cancel by time: click the button, everything off in 5 seconds.

The reason I am still using Retrospect is because, despite all of it flaws, it's the best product out there to backup a laptop (in the backup server mode).

Bring the laptop in: "Backup now or later?". You need to go, just unplug it and it sorts itself out, or click OFF in the client app: finished immediately.

Think of a backup in progress when the guy with the laptop has a plane to catch. He won't wait for QRecall to "clean up". He'll close the lid and go. If QRecall has a cancel button that does it's best in 5 seconds, he may go and click it first. If QRecall takes forever to cancel, he won't bother...

My two cents

Fred

A much more usable solution would be to simply get the actions to wrap up faster.

Not sure I understand what you mean. Usable for who ?

Yes "get the actions to wrap up faster" is what I am suggesting, only I place a limit on "faster". Improving it from 10 to 4 minutes won't be enough IMHO.