Skip to content

Transfers

Transfers land in a queue at the bottom of the tab. The queue starts transfers in the order you asked for them, runs several in parallel, and keeps going across folders recursively.

Drag between the panes, drag into the Finder, press ␣, use the toolbar’s Upload and Download buttons, or use the three-dot menu. A transfer between two different protocols in the same window works the same way — SFTP to S3, S3 to WebDAV, and so on. On S3, a bucket row is not a file: a bucket row opens, nothing else, and every transfer entry point asks the same scope, so a bucket downloads nothing.

The toolbar’s Upload and Download buttons ask before they move more than one item or a folder: Upload the selection? names how many items go where, and says when folders come along with everything in them. Choose Upload or Download to go ahead, or Cancel.

  • A single file transfers at once, without a question.
  • The files go to the folder the other pane showed when you pressed the button, even if the pane has moved on since.
  • If the tab disconnects or reconnects while the question is open, confirming transfers nothing.
  • Dragging, ␣ and the context menu never ask.
  • Parallel transfers, FIFO start order.
  • Each row shows the transfer’s progress; its tooltip or right-click menu shows and copies the full source and destination path, and a setting shows both permanently in every row.
  • Cancel a single transfer from its row, or cancel all at once — cancelAll leaves no orphaned shells or half-updated transfers behind.
  • A transfer you cancel on S3 or WebDAV reads cancelled, not “Connection lost”.
  • A failed transfer shows a readable sentence, never an internal error dump, and never a user name or password that was typed into a server address.
  • That sentence is in the language macSCP is running in. For most failures it is now the whole message — one sentence, with nothing appended. The remaining ones still add a short line marked as a technical detail; that part stays in English, and it is what to quote when you report a problem.
  • Several of these messages are worded differently than in v1.5.0. A server that answers with a code macSCP has no reading for now says so the same way whatever kind of server it is, instead of three nearly identical sentences; a folder listing that could not be read no longer repeats the reader’s own complaint after it; and a request the server sent on to another address, which macSCP declined to follow, ends in a plain sentence instead of a system message in whatever language the system wrote it in.

When the destination already exists, macSCP asks what to do: overwrite, skip, rename, or apply-to-all for the rest of the queue. Nothing is overwritten unless asked.

The queue keeps the transfers after a connection is lost, and macSCP offers the way back — reconnect and the remaining transfers resume.

The two messages quoted below are the English wording. macSCP shows them in the language it is running in, so what you see may read differently — quote the English when you report a problem.

An S3 download resumes from where it stopped only when the server sends exactly the part that was asked for. A server that ignores the request and sends the whole file, or starts at the wrong place, is refused: the row reads “S3 did not answer with the byte range asked for, so the download was not resumed” — the whole message, with nothing appended — and the partial file is left as it was.

When a download from S3 or WebDAV picks up where it stopped, macSCP first checks that the file on the server is still the one the partial download came from. If it was replaced or changed in the meantime, the resume is refused rather than joining two different files together: the row reads “The file changed on the server since the interrupted download, so nothing was added to the partial file” — the whole message, with nothing appended — and the partial file is left as it was. To get the new version, start the download again and choose overwrite when macSCP asks.

When you cancel an S3 upload that was sent in parts, macSCP asks the server to discard the parts in the background, for up to 30 seconds, so the cancel, a closed tab or a quit does not wait for it.

When a transfer fails while macSCP is in the background, or its window is not in front, macOS shows a Transfer failed notification — see Notifications.

SettingDefaultWhat it does
Maximum concurrent transfers31 to 8. Applies to new transfers; running ones are unaffected.
Always show full pathsoffShows the source and destination path in every queue row.
Bandwidth limit upload/download0 (unlimited)Per-direction limits in KB/s.
Throughput test → Test file size8 MiB1 to 256 MiB — the size of the file the throughput test sends.
Internet speed test → Speed test serviceCloudflareCloudflare, Apple or Off — which service the internet speed test measures against. Off contacts nobody.
Checksums → Checksum algorithmSHA-256SHA-256, or SHA-1 and MD5 for comparison only.

Idle connections are probed so macSCP notices when a session dies. The behaviour is a switch and an interval under Settings → General.