tar

tar is a Rust library for reading and writing TAR archives, built to work over any I/O reader or writer without requiring the whole archive to be resident in memory at once. It does not handle compression itself, leaving callers free to layer gzip, zstd, or other codecs on top via the standard Read/Write traits.

The crate exposes an Archive type for iterating over entries in an existing tar file and a Builder type for constructing new archives entry by entry, along with lower-level Header/Entry types for inspecting or crafting archive metadata such as permissions, ownership, and PAX extended attributes.

What You Get

• An Archive reader that streams entries one at a time instead of loading the whole file into memory
• A Builder writer for constructing new TAR archives from files, directories, or in-memory data
• Full Header and PAX extended-header support for permissions, ownership, and long filenames
• Generic over any Read/Write implementation, so compression codecs can be layered on top freely
• Cross-platform path and permission handling for both Unix and Windows archive entries

Common Use Cases

• Unpacking .tar.gz or .tar.zst release archives after piping through a decompression reader
• Building deployment or backup archives programmatically from a set of files and directories
• Streaming very large archives without buffering their entire contents in memory
• Implementing package-manager or container-image tooling that needs to read/write layer archives
• Inspecting archive metadata (permissions, ownership, PAX attributes) for security or compliance tooling

Under The Hood

Architecture - The crate is organized around src/archive.rs (streaming reader over entries), src/builder.rs (archive construction), src/entry.rs/src/entry_type.rs (per-entry data and type classification), and src/header.rs (the ~512-byte TAR header format plus GNU/PAX extensions in src/pax.rs). Because it works generically over Read/Write, callers compose it with any I/O source — files, network streams, or in-memory buffers — and any compression layer.

Tech Stack - A dependency-light Rust crate (edition 2021, MSRV 1.63) with a single production dependency, filetime, for cross-platform file-time metadata. Dev-dependencies include tokio/tokio-stream and astral-tokio-tar for testing interoperability with async tar implementations, plus rand and tempfile for fuzz-adjacent and filesystem-based tests. A fuzz/ directory holds cargo-fuzz targets for hardening the header/PAX parsing paths against malformed input.

Code Quality - src/header.rs alone is nearly 1,800 lines, reflecting the accumulated edge cases of the TAR format (GNU long-name extensions, PAX records, sparse files); tests/all.rs and tests/entry.rs exercise reading/writing behavior against a corpus of real-world archives under tests/archives/. The presence of a dedicated fuzz/ target and a REVIEW.md file suggests an unusually deliberate security-review process for a format-parsing library that regularly consumes untrusted input.

API Design - The two-type split (Archive for reading, Builder for writing) keeps the API easy to reason about, and both accept generic I/O types so users aren’t forced into a particular file or compression abstraction. Getting started requires only a couple of lines — open a File, wrap it in Archive::new, and iterate .entries() — with more advanced options (permissions, PAX headers) available but not required for basic use.