Transfers and sync

Transfer queue model

Uploads and downloads are job-based. Each job reports progress, state, and completion outcome in the Transfers and Activity surfaces.

Expected terminal states:

• completed
• failed
• cancelled

Expected in-flight states:

• queued
• active
• retrying

Upload behavior

Uploads support:

• single files
• multiple files
• folder uploads
• target prefix handling
• overwrite policy

The default conflict behavior is configurable:

• Ask
• Overwrite
• Skip

If conflict mode is Ask, the app does not silently overwrite existing objects.

Multipart and retry behavior

Large files use multipart upload automatically once they exceed the configured threshold.

Relevant settings:

• Parallel uploads
• Multipart threshold
• Multipart chunk size
• Retry limit
• Retry backoff strategy

The UI tells you not only that a transfer failed, but whether it retried first and with which runtime configuration.

Download behavior

Downloads can target:

• a single object
• multiple selected objects
• an expanded folder selection

The app writes temporary .part files and finalizes atomically to avoid leaving misleading partial downloads behind after failure or cancellation.

Transfer summaries

On successful completion the app shows a summary, not just a badge flip.

The operator needs:

• file count
• total bytes
• duration
• failures
• cancelled count if relevant

If those numbers are not visible, support requests become guesswork.

Sync jobs

Sync exists to make repetitive asset workflows inspectable.

Current sync modes:

• Upload mirror: local to R2
• Download mirror: R2 to local

Use a dry run before execution whenever the job is destructive or broad.

Dry run review shows:

• which files will upload
• which files will download
• which files will replace existing content
• which files will delete
• which files are skipped as unchanged

Cancellation

Cancelling a transfer or sync stops future work cleanly, but it does not mean remote state rewinds automatically.

Examples:

• A cancelled upload may have already completed some objects before cancellation.
• A cancelled download may have produced some completed local files while discarding unfinished .part files.
• A cancelled sync may have applied part of its plan before cancellation.

Read the activity trail before rerunning a large job.

Recommended operator workflow

For anything beyond a few files:

1. Set transfer runtime in Settings.
2. Stage the correct prefix.
3. Run a small sample first.
4. Review the transfer summary.
5. Only then run the full folder or sync plan.