Resuming Transfers in FileZilla: How It Works and When to Trust It

The Problem: Interrupted Large File Transfers

When uploading or downloading a multi‑gigabyte file over FTP, SFTP or FTPS, a temporary network glitch can abort the transfer. Without a resume capability you would have to start the whole file again, wasting time and bandwidth.

How FileZilla Resumes Transfers

FileZilla monitors the transfer queue. If a transfer ends with an error, it marks the entry as failed. When you retry the same file—either by clicking the queue’s Process queue button again or by dragging the file onto the site pane—FileZilla automatically sends a position‑based restart command to the server.

• For plain FTP it issues the REST command with the byte offset of the last successfully transferred block.
• For SFTP and FTPS it sends the equivalent SSH_FXP_SETSTAT or FTP‑style REST over the secured channel, telling the server to start sending data from that offset.

The server, if it supports the command, seeks to that position and streams the remainder of the file. FileZilla then continues the transfer as if nothing happened.

Worked Example: Verifying Resume on a Large ISO

1. Start a transfer of a large file (e.g., ubuntu‑22.04‑live‑server‑amd64.iso) from your FTP site to /tmp/ on your local machine.
2. After a few megabytes have been transferred, simulate a network drop—disable the wireless adapter or unplug the Ethernet cable.
3. Wait for FileZilla to show the transfer as Failed in the queue.
4. Re‑enable the network connection.
5. Select the failed entry and click Process queue (or drag the same file again).
6. Observe that the transfer resumes and the progress bar jumps to the previously transferred size.
7. Open the transfer log (View → Show log) and look for a line similar to:

Status:   Retrieving directory listing...
Command:  REST 4194304
Response:   350 Restarting at 4194304. Send STORE or RETRIEVE to initiate transfer
Status:   Downloading 4194304 bytes of 1.2GB (0.3%)

The REST line shows the byte offset where FileZilla asked the server to continue. If the server does not understand REST, you will see the transfer start from zero and the log will lack such a command.

Trade‑offs and Limitations

• Server support: Resume only works when the server implements the REST command (FTP) or its SFTP/FTPS equivalent. Very old FTP daemons or some restricted SFTP servers may fall back to a full retransfer.
• File changes: If the remote file is modified while the transfer is paused, the byte offset no longer matches the current content, which can produce a corrupted file.
• No integrity check: Resume does not verify that the resumed data matches the original via checksums. For critical data you should add a post‑transfer hash comparison (e.g., sha256sum) after the transfer finishes.
• Active‑mode firewall issues: In active mode the client must open a listener for the server’s data connection; some NAT devices block the required PORT/EPRT commands, causing the resume to fail. Switching to passive mode or configuring the firewall resolves this.

What to Do Next

If you regularly move large files over unreliable links, enable FileZilla’s transfer queue and keep the Show transfer log pane open. After each transfer, verify that a REST (or equivalent) line appears for any resumed file. When dealing with mission‑critical data, pair the transfer with a checksum check and consider using SFTP with a server known to support resume.