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. The same pause, resume, and retry behavior applies to standalone and project Offload.

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

On project Offload, a successful run updates the project file table (Synced or Remote only depending on whether you also copied locally). The active offload card on the project goes away.

On standalone Offload, you land on the result page (All copies verified when everything succeeded). Export the transfer report with Export CSV or Export PDF if you need a record. There is no ongoing project file table for that run.

Before reformatting your card or wiping your source drive, confirm zero failed files. Use Retry failed files (or Retry on the summary) until the count is zero, or accept that those specific files will not be recoverable from this source.