Pause, resume, retry

Offloads run for a long time. Cards are big, internet drops, you accidentally bump a USB-C cable, your Mac restarts during an OS update. Tusk treats every offload as inherently interruptible and persists session state to disk so that interruptions don't cost you progress.

Pause

The Pause button on an active offload immediately stops new file transfers and lets in-flight transfers finish (or roll back to a clean state). The session sticks around. The source file mid-transfer is rolled back so the destinations don't end up with half a file.

Pause is reversible: click Resume to pick up exactly where you left off. Tusk skips the files it already finished and continues from the next one in the queue.

Resume

Resume restarts a paused or auto-paused session. There are three ways a session ends up paused:

• You clicked Pause.
• Auto-pause from a disconnect. Source unplugged, destination drive unplugged, internet dropped for a cloud destination, etc. Tusk pauses the session and shows a banner explaining why. The Resume action is disabled until the missing piece comes back.
• Auto-pause across a relaunch. If Tusk quits or your Mac restarts mid-offload, the session is paused on next launch. Resume to continue.

Resume is one click. There's no “import the previous session” step. The session was already there; you just unblock it.

Cancel

Cancel ends the session. The files Tusk already wrote to your destinations stay there. The files mid-transfer at the time of cancel are cleaned up (Tusk doesn't leave half files lying around). The session is gone; you can't resume it after canceling.

To “redo” a canceled session, start a new offload from the same source. Tusk will detect the already-completed files via its preflight conflict check and offer Skip or Overwrite.

Retry on individual file errors

Within a session, individual file errors are normal. A flaky USB connection drops a single file, a cloud destination returns a transient 503, a checksum mismatches because of a read error. Tusk handles these inline:

• Each error is logged against the file with a clear reason (read error, checksum mismatch, network timeout, etc.).
• The file's row in the table flips to Error.
• The session continues with the rest of the files. One failed file doesn't block the queue.
• When the session ends, the offload summary shows a count of errored files and a Retry button to re-attempt them without redoing everything else.

You can also retry an individual file from its row in the file table (three-dot menu → Retry).

What happens to the destinations on a partial finish

If you cancel mid-offload, the verified files on the destinations stay where they are. Their statuses in the file table reflect the partial state (Synced for files that finished cleanly, no entry for files that hadn't started yet). The half-transferred file at the moment of cancel is cleaned up so you don't have a corrupted partial.

What happens after a clean finish

When the session completes successfully, Tusk shows a summary card with file count, total bytes, time taken, and a per-destination confirmation. The active offload card on the project page goes away and the file table reflects the new state (every file Synced or Remote only depending on your copyLocally choice).

Before reformatting your card or wiping your source drive, double-check the summary shows zero errors. If there are any errors, click Retry until the count is zero.