Zfile types
ZIP file transfer
The copy of a ZIP archive that packages many files into one object so the transfer has one size, one hash, and one resume point.
How it works
ZIP stores a table of contents at the end. A truncated download can look like a file and fail only when the client reads that table. Binary mode is required on FTP. HTTP does not care. Compression helps text and hurts already compressed video. The hash of the archive covers the set. A hash per member is how you find the one bad file.
A photographer zips 2,400 JPEGs, 3.2 GB. The upload completes. The recipient's unzip stops at 98 percent because the central directory never arrived. Size is 3.1 GB, short of the published 3.2. They resume. A second zip made on macOS includes __MACOSX entries the Windows tool treats as junk. The pictures are fine. The packaging was noisy.
How it differs
A ZIP transfer is not a folder transfer. The folder is many objects. The ZIP is one. Losing the ZIP loses the manifest. Losing one file in a folder leaves the rest.
Encrypting the ZIP and putting the password in the same mail collapses the control. Send the password on a second channel.
Some tools cannot open ZIP64. Archives over 4 GB need a tool that understands ZIP64 or they fail on open after a perfect transfer.
On the ticket
- The practical close is a log line: time, actor, byte count, result.
- Without that line the transfer is a story.
- With it, the next person can see whether this door did what the ticket claimed.
- If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
Related
Sources
- RFC 9110, HTTP Semantics
Methods and status codes for the transfer