Disconnect & reconnect

The whole point of Tusk treating destinations as first-class entities (instead of folder paths it's actively writing to) is that destinations are allowed to go away and come back. The lifecycle of a drive being plugged in, used, unplugged, and replugged is the everyday case, not a failure mode.

What happens at disconnect

• Tusk detects the eject within a couple of seconds (it listens for macOS volume mount/unmount events).
• Any in-flight transfer to that drive is rolled back so the destination doesn't end up with a partial file.
• Sync jobs targeting that drive are paused. Sync to other destinations on the same project keeps running.
• The drive's connection state in the Drives page flips to Disconnected with a “Last seen” timestamp.
• The destination's entry in the project's locations panel shows an offline indicator.
• File table cells for that destination show their last confirmed state plus a small offline marker.

What happens at reconnect

• Tusk detects the mount within a couple of seconds.
• Tusk runs a fresh stat pass against every file it expects to find on the drive. Most of these come back verified almost instantly. Anything missing or changed is surfaced via the live deletion detection mechanism (covered on the Live deletion detection page).
• Queued sync jobs that piled up while the drive was offline start running. Tusk pushes any new files (added or edited locally during the outage) to the drive in order.
• The Drives page connection state flips to Connected.
• The project's locations panel updates and the file table cells lose their offline markers.

Mid-offload disconnect

If a drive disconnects during an offload (either as source or as destination), Tusk pauses the offload session with a clear banner naming the disconnected drive. The session state is persisted to disk; replug the drive and click Resume to continue. Bytes already transferred are skipped. The full offload pause/resume semantics are on the Pause, resume, retry page.

Mid-restore disconnect

Similar story for restores. If the source drive Tusk was reading from disconnects, Tusk falls over to the next fastest source automatically (where one exists) and continues. If no fallback exists, the restore pauses until you replug.

How Tusk distinguishes a graceful eject from a yanked cable

From Tusk's point of view, both look the same: the volume disappears. The recovery logic doesn't change based on which one happened. That said, a clean macOS eject (Cmd-E in Finder, or the eject icon in the sidebar) gives in-flight transfers a chance to flush before the volume goes away. Yanked cables can leave partial writes that Tusk has to detect and clean up on reconnect (the cleanup happens automatically; you don't need to do anything).

Cloud destination disconnects

Cloud destinations “disconnect” in two ways:

• Your internet connection drops. Tusk pauses the cloud sync queue and resumes when network connectivity is back. Local sync to drives keeps running.
• Credentials expire (Google Drive OAuth token, or you rotated an S3 key without updating Tusk). Tusk surfaces a notification with a deep link to Preferences > Accounts to refresh the credential. Re-authenticate and sync resumes.