snappy(1)

snappy1

Snappy compression and decompression with and without framing

Usage

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

snappy -d [-i] [file]

unsnappy [-i] [file]

Overview

Without -d, compresses file (standard input stream if "-", the default) with Snappy to the standard output stream, then assesses the compression ratio achieved to the standard error stream.
With -f, the Snappy framing format is produced.

When run as unsnappy, or with -d, decompresses file (likewise) from Snappy, or the Snappy framing format (detected automatically), to the standard output stream.
With -i, decompression and framing errors are ignored and processing continues.

As a format limitation, if file isn't seekable when producing or decompressing unframed Snappy streams, it will be read into memory in its entirety.

Exit status

1

If a decompression error (invalid or truncated Snappy block) or a framing error (Stream identifier (0xFF) frame invalid, unknown reserved unskippable chunk ([0x02, 0x7F]) frame encountered, checksum mismatch).

2

On an I/O error.

3

When compressing without -f and file is larger than 4GiB. (Output unaffected, but see BUGS.)

Diagnostics

After compressing,

data: 2048576 -> 1099105 (53.65%)

means that the file data was 2048576 bytes, which were compressed down to 1099105 bytes, and the output is thus 53.65% the size.

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 library “libsnappy”.

Bugs

The largest representable unframed stream is of size 4GiB-1B (= 4·1024·1024·1024B-1B = 4294967295B). Above this size the length stored in the header becomes mangled, so the stream may be semantically correct but will produce an incorrect (short) output when decompressing. snappy warns about this and exits 3.

On 32-bit systems it is impossible to produce unframed streams from files larger than 4GiB-1B at all due to an API limitation (EXIT STATUS 2). On 32-bit systems the output size and compression ratio will be misrepresented if compression produces an unframed output larger than 4GiB-1B. It is also impossible to decompress such files there.

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

From snappy-tools 1-1 in Debian 13 (Trixie). Parsed by carta from the page's mdoc source.