How FileZilla Resumes Interrupted Transfers and When It Might Fail

Problem: Interrupted transfers waste time and bandwidth

When a network glitch or client crash stops an FTP or SFTP upload, the client often has to start the file from the beginning. This re‑transfers already‑sent bytes, consuming bandwidth and extending the total transfer time, especially for large files.

How FileZilla’s resume works

FileZilla implements the FTP REST command (or its SFTP equivalent) to tell the server the byte offset of the last successfully transferred block. When a transfer is paused or fails, the client stores that offset in its transfer queue. On reconnection it issues REST , the server seeks to that position, and the transfer continues from there. The feature is active for plain FTP, FTPS and SFTP, provided the server advertises support via the FEAT command or SSH extensions.

Worked example: resuming a 2 GiB upload

1. Start uploading a 2 GiB file to an FTP server with FileZilla.
2. After roughly 800 MiB have been sent, disconnect the network cable or disable the wireless interface.
3. FileZilla marks the transfer as failed and logs a line similar to Status: Interrupted transfer, 838860800 bytes transferred.
4. Re‑enable the network and click the queue’s “Process queue” button.
5. FileZilla reconnects, sends REST 838860800, the server seeks to that offset, and the log shows Command: REST 838860800 followed by Status: Resuming transfer and the upload continues from the 800 MiB point.

Trade‑offs and limitations

• The server must allow the REST command (or positional write in SFTP). Some hardened FTP servers disable it for security, causing FileZilla to fall back to a full restart.
• If the remote file changes size or content between interruptions, FileZilla detects a mismatch (via size or hash if available) and aborts the resume, requiring a fresh transfer to avoid corruption.
• For very small files the overhead of storing checkpoints and issuing REST can outweigh the benefit; FileZilla lets users set a minimum file size (default 0 MiB) for which resume is attempted.

Actionable steps to verify and tune

1. Confirm you are running a recent stable release (Help → About). The resume feature exists since at least FileZilla 3.0.
2. Enable detailed logging: Edit → Settings → Debug, set “Show debug log” and optionally log to a file.
3. Perform a test: queue a file larger than 5 MiB, start the transfer, interrupt it midway, reconnect, and watch the log for a REST line and a “Resuming transfer” status.
4. If you notice many resume attempts on tiny files, adjust the threshold: Edit → Settings → Transfers → File types, set “Minimum file size for resume” to a value like 1 MiB.

By understanding how FileZilla’s checkpoint restart works, you can rely on it to save bandwidth for large transfers while knowing when to expect a full restart and how to tune the behavior to your environment.