SNAPPY(1)

💖 SNAPPY 💖

okay bestie, so snappy and unsnappy are the little tools that do Snappy compression and decompression — with framing and without it. both of them. same page, two names. it's giving twin energy fr fr ✨

---

✨ SYNOPSIS ✨

snappy [-f] [file] > snappy.sn|.sz

snappy -d [-i] [file]
unsnappy [-i] [file]

---

🌸 DESCRIPTION 🌸

No -d in sight? Then we're compressing, babe. It takes file — and if file is "-", or if you just don't give one at all (that's the default), it reads the standard input stream — squishes it with Snappy, drops the result on the standard output stream, and then tells you how good the squeeze was by writing the compression ratio to the standard error stream. And with -f, you get the Snappy framing format instead. periodt.

Running as unsnappy, or passing -d? Now we're decompressing. Same file rules as above (yes, "-" and stdin defaults still apply 💅), and it goes from Snappy — or from the Snappy framing format, which it detects automatically — out to the standard output stream. Add -i and decompression errors and framing errors just get ignored, and processing keeps going like nothing happened. iconic, honestly.

⚠️ Real talk, this is a format limitation: if file isn't seekable while you're producing or decompressing unframed Snappy streams, the whole thing gets read into memory. In its entirety. All of it. 💀

---

💅 EXIT STATUS 💅

• 1 — a decompression error happened (invalid or truncated Snappy block), or a framing error did (Stream identifier (0xFF) frame invalid, unknown reserved unskippable chunk ([0x02, 0x7F]) frame encountered, checksum mismatch).
• 2 — an I/O error happened. rip.
• 3 — you were compressing without -f and file is bigger than 4GiB. (The output itself is unaffected, but go peek at “BUGS” below 👀)

---

🩺 DIAGNOSTICS 🩺

After compressing, you might see something like this:

data: 2048576 -> 1099105 (53.65%)

which means the file data was 2048576 bytes, and it got compressed down to 1099105 bytes, so the output is 53.65% the size. math ate, no cap 🍓

---

🔗 SEE ALSO 🔗

The Snappy homepage: https://google.github.io/snappy/ — go look, bestie 🦋

---

👑 CONFORMING TO 👑

The framed format, with MIME type ‘application/x-snappy-framed’, version 2013-10-25: Snappy framing format description: https://github.com/google/snappy/blob/main/framing_format.txt.

The unframed format, as described in Snappy compressed format description: https://github.com/google/snappy/blob/main/format_description.txt, as provided by the upstream Fast Compressor/Decompressor Library (libsnappy, -lsnappy).

---

💀 BUGS 💀

okay so the largest representable unframed stream is of size 4GiB-1B (= 4·1024·1024·1024B-1B = 4294967295B). Go above that and the length stored in the header gets mangled — the stream might still be semantically correct, but it'll produce an incorrect (short) output when you decompress it. snappy warns you about this and exits 3. not a vibe.

On 32-bit systems, it is literally impossible to produce unframed streams from files larger than 4GiB-1B at all, thanks to an API limitation (“EXIT STATUS 2”). Also on 32-bit systems, the output size and compression ratio will be misrepresented if compression produces an unframed output larger than 4GiB-1B. And you can't decompress such files there either. rough out here 😭

Supposedly, compressors which produce checksums with inverted byte order exist in the wild. wild wild.

---

and that's the whole page, bestie!! this one's from snappy-tools 1-1, dated February 15, 2024 — mwah, go compress something 🎀🫶