FileZilla Auto-Resume: How It Works and When to Use It

Why interrupted transfers hurt

When a network drop occurs during a large FTP or SFTP upload, the client has no record of how many bytes were already accepted by the server. Without a resume mechanism the only option is to start the transfer again from byte 0, re‑sending data that already arrived correctly. This wastes bandwidth and can turn a few‑minute upload into a much longer ordeal, especially on metered or slow connections.

How FileZilla’s auto‑resume works

FileZilla can ask the server to continue from a specific offset using the FTP REST command (or the SFTP positional‑write extension). After a disconnect it:

1. Looks for a partial file with the same name in the local transfer queue.
2. Queries the server for the size of the remote file (via SIZE for FTP or stat for SFTP).
3. If the sizes match, it sends REST with the offset equal to the local file size and resumes the stream.
4. If the remote file differs in size or the server does not advertise resume support, FileZilla falls back to a full retransfer and logs a warning.

Worked example: rescuing a 2 GB video upload

1. You start uploading video-2026.mp4 (≈2 GB) to an FTP server over a Wi‑Fi link.
2. After about 1.3 GB have been transferred, the Wi‑Fi drops.
3. FileZilla marks the transfer as "failed" and keeps the local partial file video-2026.mp4 in the transfer queue.
4. When the connection returns, you click the queue entry and choose "Process queue" (or let Auto retry kick in).
5. FileZilla checks the log, sees the server’s FEAT response contained REST, queries the remote size, finds it matches the local 1.3 GB, sends REST 1374389534 and continues streaming the remaining bytes.
6. The upload finishes without re‑sending the first 1.3 GB, saving roughly 35 % of the total transfer time.

When resume can fail and what to check

• Server does not really support REST – some old FTP daemons list REST in FEAT but return an error when the command is issued. FileZilla will retry and may get stuck in a loop; disabling Auto resume for that host avoids the problem.
• Remote file changed – if another process overwrote or truncated the file while you were offline, the size check will differ and FileZilla will warn that resuming could corrupt the file. In that case you must decide whether to keep the local version or start fresh.
• SFTP nuances – resume relies on the server’s ability to write at a given offset (POSIX‑style pwrite). Older SFTP implementations may lack this; FileZilla will log a failed resume attempt and fall back to a full transfer.

Practical trade‑off and recommendation

Enabling Auto resume costs virtually nothing in terms of CPU or memory, but it relies on the server advertising correct resume support. For most modern FTP/SFTP servers (vsftpd, ProFTPD, Pure‑FTPd, OpenSSH sftp) the feature works reliably. The only situation where you might want to turn it off is when you manage a legacy FTP daemon known to falsely advertise REST or when you frequently overwrite files and need to be certain that a resumed transfer does not silently corrupt data.

Actionable checklist

• Open Edit → Settings → Transfers → File types and make sure Auto resume is checked.
• Connect to your host and watch the message log for the line containing FEAT; verify that REST appears.
• Upload a test file larger than 100 MB, pause it manually (right‑click → Pause), then reconnect and confirm that the queue shows the transfer resuming from the paused byte offset.
• If you see repeated 500 REST not understood errors, disable Auto resume for that host via Site Manager → Transfer settings and uncheck Auto resume.

With these steps you can let FileZilla handle the heavy lifting when connections drop, turning a frustrating restart into a seamless continuation.