Theme
Transfers Preview
Automation, then Transfers lists every transfer job a script on this Connector asked your Head to run: the ones running now, with their progress, and the ones that finished, with their outcome.
Nothing appears here on its own. A row exists because a script called SubmitTransfer, from an event handler or a schedule.
What a row shows
| Column | Meaning |
|---|---|
| When | When the script submitted it |
| Head | The Head that runs it |
| As user | The automation identity the job runs as |
| Operation | Copy, move, or sync with its mode (update or mirror; a dry run says so) |
| Source, Destination | Paths in that identity's namespace |
| Progress | Bytes moved of bytes expected, and files, while it runs. A sync adds what it planned and applied (copied, deleted, skipped, conflicts, failed) and a warning when it had to trust file sizes alone |
| State | queued, running, done, failed, canceled, interrupted (the Head was upgraded mid job), or lost (the link stayed down too long to learn the outcome) |
| Triggered by | The event or the scheduled run that submitted it |
| Error | The reason, when the job did not complete |
The page updates itself while a job runs; there is nothing to refresh.
Canceling
Cancel on a running row asks the Head to stop the job. What was already copied stays where it landed; a move never deletes a source file before its copy was verified, so a canceled move loses nothing.
Where the job actually runs
The Connector only asks. The Head runs the job as it runs a copy or move from the web client: between two storages on one Connector the bytes never leave that Connector; between two Connectors they pass through the Head. The job survives this page being closed, and even a Connector restart: on reconnection the Connector picks the job up again by its id and records the outcome when it learns it.
History
Finished jobs stay in the list for a day, and their outcomes are kept as records for the same retention as scheduled run records, set under System, Settings, Scheduler.