Check whether the upload can resume
Keep the original file and reopen the transfer in the application that started it. Look for that upload's own resume action. If you used a script, keep its saved transfer state before running anything again. Starting another upload may create a separate attempt that cannot use the bytes already received.
Resuming requires support from both the sender and the receiving service. A resumable transfer remembers accepted progress so the sender can continue from a known point. An ordinary upload may offer no way to recover unfinished work. If the application has discarded its transfer state or the destination no longer recognises it, you may need to start again.
For HTTP uploads, curl's continue option cannot resume POST or PUT requests; check the receiving API's documentation for its recovery procedure. HTTP permits partial PUT by agreement between client and server, but support is inconsistent. Sending only the remaining bytes to an ordinary upload address can replace the intended file with that fragment. A download resume example therefore cannot establish that your upload will resume.
Separate sent bytes from confirmed progress
A connection can fail after the server accepts data but before its reply reaches you. Your script sees an error in either case, so a failed request without an acknowledgement leaves you unable to distinguish data that never arrived from data that the receiver has already accepted. Your progress bar may count bytes sent rather than bytes the receiver has acknowledged. Use it to choose a resume position only if the application documents that it reflects confirmed acceptance.
Use the service's documented status check when one exists. Compare that result with your saved progress before sending more data. Some upload systems track a continuous accepted portion, while others acknowledge separate pieces. The sender must follow the model its service supports. Guessing the next position from elapsed time can leave a gap or repeat bytes.
When there is no status check, recovery depends on documented retry behaviour and acknowledgements you saved earlier. Only resend an uncertain piece when the service guarantees that repeating it will produce the intended result. If that behaviour is unspecified, stop and establish the transfer's state before finalising it. Repeated requests cannot resolve an ambiguity they keep reproducing.
| Transfer state | Next action | Evidence to retain |
|---|---|---|
| Confirmed progress | Keep accepted work | Save the receiver's acknowledgement alongside your transfer record. |
| Uncertain progress | Check before retrying | Use documented status information or safe retry behaviour. |
| Verified completion | Release the file | Keep the final receipt and the result of content verification. |
Resume from the same source file
The remaining bytes must come from the file you originally started sending. The filename alone cannot establish that relationship. A build job might replace an archive at the same path while your connection is down, so continuing from that replacement could combine the beginning of the old archive with the end of the new one.
Keep a stable copy for the duration of the transfer. Record enough information to recognise that copy when the sender restarts, including its length and a locally calculated content digest. Compare those details before continuing after a crash. When your file has changed, create a fresh transfer from the intended source rather than combining different outputs.
Save confirmed progress somewhere the sending job can recover after it exits. That record should associate the source copy with the destination and the unfinished transfer. Keep credentials out of ordinary job logs and public error reports. Someone investigating a disconnect needs the failure stage and request outcome, without receiving the authority to upload files themselves.
Confirm completion before handing the file over
Sending the remaining bytes does not necessarily make the file ready for its reader. Some services require an explicit completion request after the pieces arrive. Wait until every outstanding send has finished. Finalising while data is still arriving can publish an incomplete result unless the service explicitly prevents it.
A lost completion response needs a separate check. The upload might already have produced a finished file, even though your client reports failure. Find the expected completed result through the service's documented read or status operation. An unfinished transfer may also disappear after cancellation or expiry, so finding that it is missing leaves you with an unresolved outcome until you can verify the expected completed file.
After completion, verify the downloaded result against the retained source. Comparing content digests can reveal missing or changed bytes, provided the expected digest came through a trusted path. Record the specific completed version when the destination supports versions. A reader fetching the newest file later could otherwise receive a subsequent upload and mistake it for this attempt.
Test recovery before relying on it
Use a disposable file to rehearse the failure you expect. Interrupt its connection during transfer, restore connectivity and check that the sender continues within the existing attempt. Compare the finished result with the source. Repeat the exercise with a sender restart if your job runner may stop as well as lose network access.
Include the awkward case where the sender misses a successful response. Your recovery procedure should explain how to discover whether that operation completed. For svc.nz, resumable uploads support sending pieces and committing them into a version; hosted access remains an invite-only private trial. Confirm the recovery operations available in your chosen client before making that workflow part of an unattended job.
Open your current upload's documentation and identify how it records accepted progress and confirms completion. Then retain the source file and rehearse a disconnect with disposable data. When accepted progress remains unknown, record that uncertainty and arrange a fresh attempt before giving a recipient the download address.
FAQ
Can I resume an ordinary curl upload?
Resuming an HTTP upload with curl requires separate requests following the endpoint's documented procedure, because curl's continue option cannot resume POST or PUT requests. The curl command alone cannot make an ordinary destination retain unfinished work. Check the endpoint's documentation before sending a partial file.
Can I close my laptop and continue later?
Continuing later requires the application to retain its transfer state and the receiver to keep recognising that upload. Your original file must also remain available and unchanged. Check those conditions before closing the application or moving the file.
Should I retry when the final response is missing?
Check whether the expected finished file already exists before repeating the completion operation. A lost reply can conceal a successful upload. Use the service's documented recovery behaviour and verify the resulting content before marking the transfer complete.
Sources
HTTP Semantics: partial PUT support and compatibility; curl documentation: continuing transfers.