Inspect size, time, and resume support

Big downloads fail mid-stream on flaky Wi-Fi and long VPN paths. Before you blindly restart from zero, check whether the server can tell you the file size and restart at an offset.

Not every host supports that. I run feat first and read the list. If REST STREAM is missing, resume is not on the table for that server.

Even when REST exists, verify the remote file did not change mid-download. Size alone is a weak check. Compare a hash when the file matters. I keep a small script that compares SIZE before and after a retry.

Run feat on your test host:

ftp> feat
211-Features:
 SIZE
 MDTM
 REST STREAM
211 End

SIZE returns a byte count. MDTM returns a modification time in UTC. REST STREAM lets you resume a download when the server allows it.

Check the remote file, set binary mode, then restart:

ftp> type i
200 Type set to I
ftp> quote size archive.tar.gz
213 104857600
ftp> quote rest 52428800
350 Restarting at 52428800
ftp> get archive.tar.gz
150 Opening data connection
226 Transfer complete

Your local partial file must already be 52,428,800 bytes. If the length does not match the restart marker, delete the partial file and start over. Guessing the offset gives you a corrupted archive that unpacks with a vague error an hour later.

MDTM helps you spot a changed file:

ftp> quote mdtm archive.tar.gz
213 20260730101522

That is metadata, not a hash. FTP has no standard SHA-256 command everyone implements.

Some servers only allow REST on downloads, not uploads. Try a small file on your host before you wire this into cron. A failed resume beats a corrupted file.

Create a partial download, resume it, and compare shasum -a 256 with a known-good copy. Then replace the remote file and watch size-only checks miss the swap.