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. In the desktop app, 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 desktop app carries on by itself when the network, the computer or the app is back. If a source file changed meanwhile, the desktop app asks first instead of resuming.
Where it works
In the desktop app for macOS, Windows and Linux, uploads and workspace downloads resume by themselves, and watch folders keep their state, so after a restart they send only what is left. In a browser, an interrupted upload or download starts again from the beginning; that is how a browser transfer works. The phone app works the same way today.
- Desktop app: resume after drop, sleep, reboot or quit; watch folders restart-safe
- Browser and phone app: an interrupted file starts again; finished files stay finished
- Desktop app: 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 render farm delivering overnight, a games studio shipping a build before a deadline: all of them start transfers nobody will be watching, which is why they belong in the desktop app. 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 in the desktop app 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. Resumed in the desktop app, 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.