What resume really means
A transfer of a 1 TB folder is thousands of files and a long tail of partial ones. A tool that “retries” starts the current file again, and a tool that only remembers which files finished throws away hours of a single large file. Boita’s accelerated transfer engine checkpoints as it runs: when a transfer restarts, files already on the server are skipped, and a file that was part-way through continues from where it reached rather than from zero.
That holds across the interruptions that actually happen: the Wi-Fi drops, the lid closes, the machine reboots for an update, you quit the app, the office loses power overnight. Reopen the app, or let the agent restart under systemd, and the queue carries on; nothing that already arrived is re-sent.
Where it works
On the desktop app for macOS, Windows and Linux, every upload and download resumes, including watch folders: state is kept locally, so a restart does not re-scan or re-upload the tree. On the headless Linux agent and the boita CLI, a job that dies with the shell or the host resumes when it is run again. On the browser path, with nothing installed, an upload or download over HTTPS resumes after an interruption too; it is slower than the fast path, and also what Boita falls back to when a network blocks UDP.
- Desktop app: resume after drop, sleep, reboot or quit; watch folders restart-safe
- Linux agent and CLI: resume when the job runs again
- Browser path: resumable over HTTPS, slower, nothing to install
- Completed files never re-sent; partial files continue from their checkpoint
Why it matters: site offices, field laptops, overnight jobs
A survey team offloading a week of captures from a site cabin, a field laptop sending microscopy stacks from a hotel, a hospital pushing a study to a referral centre, a render farm delivering overnight, a NAS copying to a second site after hours, a games studio shipping a build before a deadline: all of them start transfers nobody will be watching. Without real resume, a two-second outage at three in the morning costs the whole night. With it, it costs two seconds.
Tokens, revocation and checksums after a resume
Every download runs on a token minted for that download, scoped to exact paths and one direction, expiring in minutes; a resumed download is issued a fresh token from the same link, so a recipient who lost their connection can carry on. The other side of the same design is revocation: pull the link and there is no token to resume with, so new and resumed transfers stop at once rather than at the next expiry.
The server records a checksum, SHA-256 or SHA-512 as chosen per workspace, for every file once it is complete, whatever route it took. A file assembled across three sessions and two reconnects carries one checksum for the whole file, shown in its details, and the delivery receipt shows the integrity check on every completed download; a half-written file cannot be mistaken for a finished one.
A worked example
A 1 TB job on Pro over a 1 Gbps line runs at the plan ceiling of 450 Mbps and takes about 4.9 hours. Say the connection drops at hour three: about 607 GB has arrived. On resume the remaining 393 GB takes about 1.9 hours, so the job finishes at roughly five hours instead of eight; a tool that restarts from zero pays the full 4.9 hours again. How long an ordinary upload would take depends on distance and loss; the calculator on the home page models it.