Why must a gzip.Writer be closed before the file is valid, and what breaks if its Close error is dropped?

## What a gzip member looks like on the wire A gzip stream (RFC 1952 calls one a *member*) has three parts: a 10-byte header with the magic bytes, a compression-method byte and optional fields such as `ModTime` and `Name`; a body of DEFLATE-compressed blocks; and an 8-byte **trailer** holding the CRC32 of the *uncompressed* bytes and ISIZE, the uncompressed length modulo 2^32. That layout explains the whole question. The CRC and the length cannot be known until the producer has seen every byte, so they can only be written at the very end — and in Go the only thing that writes them is `(*gzip.Writer).Close`. ## What Write, Flush and Close each do `gzip.NewWriter(w)` wraps `w` and starts a DEFLATE compressor over it. Each call to `Write` feeds bytes into that compressor, which accumulates them into blocks; a block is only emitted once the compressor has enough input to encode it well. So after your last `Write` returns, some of your data is still living in the compressor's internal window, not in `w`. `Flush` pushes the pending compressed bytes out and ends the current block so a reader can decompress everything written so far, but it does **not** finish the member — no trailer, and you may keep writing. `Close` is the terminator: it flushes, closes the DEFLATE stream, and appends the trailer. After `Close` the member is complete and the writer must not be written to again (though `Reset` makes it reusable for a new destination). ## What a truncated member does to the reader If you never call `Close`, the file ends mid-stream. `gzip.NewReader` will happily open it, because the header is intact, and decompression will return real data for a while — then `Read` fails with `io.ErrUnexpectedEOF`. If the trailer is present but the data was corrupted, the reader fails with `gzip.ErrChecksum` instead. Note the reading-side counterpart: the checksum is only verified once the stream is consumed to `io.EOF`, so a reader that stops early never learns the file was damaged. This is exactly the failure that pages someone at 3 a.m. for a log-shipping agent: the rotated `.gz` files it uploaded look plausible, most of the lines are there, and the last chunk of every file is missing. ## Why the Close error matters `Close` performs I/O, so it can fail — a full disk, a broken pipe, a closed socket. That failure lands on `Close` and nowhere else, because the earlier `Write` calls succeeded into a buffer. `defer zw.Close()` discards it, and the function returns `nil` while the archive is broken. The idiom is a named result plus a deferred closure: ```go func writeGz(path string, src io.Reader) (err error) { f, err := os.Create(path) if err != nil { return err } defer func() { if cerr := f.Close(); err == nil { err = cerr } }() zw := gzip.NewWriter(f) if _, err = io.Copy(zw, src); err != nil { return err } return zw.Close() } ``` Because `err` is a named result, `return zw.Close()` assigns it before the deferred function runs, so the deferred close only overwrites a `nil` error and never masks a real one. ## Ordering and layering `(*gzip.Writer).Close` does not close the `io.Writer` underneath it — the doc is explicit about that, and it is why you own two closes. The order is bottom-up in construction and top-down in shutdown: close the `gzip.Writer`, then the file. Reversed, the trailer is written to an already-closed file and you get an error you then have to handle anyway. A `bufio.Writer` between the compressor and the file adds a third step: `zw.Close()`, then `bw.Flush()`, then `f.Close()`. `bufio.Writer` has no `Close`, so nothing will flush it for you, and forgetting it truncates the file just as surely as skipping the gzip trailer. ## What to say in an interview The short version: compression is buffered, the trailer carries a checksum that can only be computed at the end, `Close` is the only thing that writes it, and `Close` returns the error for the final write. Everything else follows.