Resuming: acknowledgement, checkpoint and receipt are different
Five signals that sound alike and mean different things, and what resuming actually keeps.
Five signals sound alike and mean different things:
| Signal | What it states | What it does not prove |
|---|---|---|
| Bytes written | The local sender has handed bytes to its transport | Complete receipt or file storage |
| Chunk acknowledgement | The transport chunk in question was acknowledged by the protocol | The whole file stored durably |
| Durable checkpoint | A defined verified prefix is saved together with its restart state | A finished whole transfer or an activated folder state |
| Signed receipt | The complete receipt checked for this profile | A storage location confirmed universally in the browser |
| Activation or management receipt | The separately authorized follow-up action has finished | A general program start on the target |
Scroll sideways to see the whole table.
Resuming preserves the transfer ID, the receiver binding and the cryptographic preparation. A transport switch does not change the file and does not encrypt changed source data with old nonces. For normal prepared files the local cipher cache can replace the source. With the native folder stream the originals stay necessary until completion.
On the directory receiver, a checkpoint is reported as durable only after the required data and directory synchronizations and the atomic journal switch. After a restart, plaintext bytes that already exist are checked for integrity again. A UI counter that had already moved on is no substitute for this point. When the receiver's position is unknown, pipeit shows “unknown” instead of zero.
Resume granularity depends on the profile: the file profile restarts an attempt from its cipher cache without re-encrypting; directory and live streams resume from their last durable checkpoint.
Errors have meaning as well: receiver_blocked with a concrete receiver status differs from a missing network connection. A full disk is not emptied by the relay (server route). A valid receipt that already exists must not be reinterpreted as a new double send because of a later status read error. For practical steps see Status, progress and resuming.
Related guides
- Command line and servers
Status, progress and resuming
Read the state of a transfer and continue the same job instead of starting a new one.
From sending to verified receipt
The factual order of an online transfer: order, acceptance, encrypted frames, verification and a signed receipt.
Folder streams and safe target directories
How a native folder is sent without a full archive, what the receiver checks and why the modes differ.