Commit Graph

2 Commits

Author SHA1 Message Date
Phillip Susi 89de9a5026 Add proper cancel support (#601239)
Interested operations can now connect a signal to their OperationDetail
to be notified of a cancelation request.  The internal copy/move code
will now cleanly stop on cancelation, allowing the partition to be
rolled back to its previous state.  This makes canceling a move
perfectly safe.

After clicking cancel, the button changes to "Force Cancel" and is
disabled for 5 seconds.  Operations that are safe to cancel will do so
and those that are not will continue to run.  Clicking force cancel
asks operations to cancel, even if doing so is unsafe.  For the
internal copy/move algorithm, canceling is always safe because an
error results in a rollback operation.  Canceling the rollback is
unsafe.  For external commands, filesystem modules may indicate
that the command is safe to cancel or not.  Canceled commands will
be terminated with SIGINT.

As a result of the new safe cancel vs force cancel distinction, the
scary warning about cancl causing corruption has been moved to
after clicking the force cancel button.

Part of Bug #601239 - Please allow 'Cancel after current operation'
2013-03-11 18:40:31 -06:00
Phillip Susi bd9e16f22f Thread the internal copy algorithm (#685740)
Have the copy code create a background thread to do the actual copying so
that it won't block the main loop.

Part of Bug 685740 - Refactor to use asynchronous command execution
2013-03-11 18:40:31 -06:00