Browse archives · Novus Examples

GDPR Export — JSON Only (ZIP, SAMPLE)

SAMPLE subject-access ZIP with JSON profile/preferences only — fictional PII.

File: ZIP · Exports · 3 members
Use case: Privacy export testingData import+1

GDPR Export — Nested Paths (ZIP, SAMPLE)

SAMPLE nested-folder GDPR export with JSON + JSONL members — fictional PII.

File: ZIP · Exports · 4 members
Use case: Privacy export testingData import+1

GDPR Messages Export (JSON, SAMPLE)

Standalone SAMPLE messages JSON fragment for privacy-export parsers.

File: JSON · Exports
Use case: Privacy export testingData import

GDPR Preferences (TOML, SAMPLE)

SAMPLE consent/preferences TOML for privacy-export parsers.

File: TOML · Exports
Use case: Privacy export testingEditor testing

GDPR Sample Data Export (ZIP)

A small ZIP shaped like a GDPR subject-access export — profile JSON, activity CSV, consents JSON, and a README. All PII is fictional SAMPLE data.

File: ZIP · Exports · 4 members
Use case: Data importConversion testing+1

GZ - Gzip Single File

A single text file compressed with gzip — the container-free codec on its own, for testing decompression and codec detection.

File: GZ · Compressed · gzip
Use case: Conversion testing

ISO - 9660 Disk Image

A real ISO 9660 disk image with Joliet and Rock Ridge extensions for long filenames, holding a few documented text files. For testing ISO mounting, extraction, and conversion.

File: ISO · Disk Image · 3 members
Use case: Conversion testing

JAR - Resource Archive

A Java Archive (JAR) — a ZIP with a META-INF/MANIFEST.MF and resource files only (no .class bytecode). For testing JAR/ZIP readers and manifest parsing.

File: JAR · Zip · 4 members
Use case: Conversion testing

Preview of JAR With a Nested Library JAR — Actual file preview for JAR With a Nested Library JAR

The nested-JAR layout an executable fat jar uses: a manifest with a Class-Path entry and a second JAR stored uncompressed under BOOT-INF/lib so it can be read in place without being extracted first. It contains resources only - properties, JSON and text, no compiled bytecode - and the manifest uses the CRLF line endings the JAR specification requires.

File: JAR · Nested Mixed · 4 members
Use case: Conversion testingMetadata testing· Conversion set

LZ4 — Single File

A text file compressed with the LZ4 frame format (.lz4) — the container-free codec on its own — for testing LZ4 decompression and codec detection.

File: LZ4 · Compression · lz4
Use case: Compression testingConversion testing

Static Website Project (ZIP)

A realistic static-website project bundled as a ZIP — index.html with linked CSS, JS, and an SVG logo, plus a README. For testing project extraction, unpack-then-serve pipelines, and nested-folder handling.

File: ZIP · Project · 5 members
Use case: Conversion testing

TAR - Directory Members and an Empty Directory

Three directory records with distinct modes, one of which - tree/empty/ - has no members underneath it and therefore exists only because the record does. A reader that synthesises directories from member paths alone silently loses it, and loses the 0750 and 0700 modes on the other two.

File: TAR · Tar Records · 5 members
Use case: Conversion testingMetadata testing· Conversion set

TAR - Empty Archive

An empty tar is not a zero-byte file - it is exactly two 512-byte blocks of zeros, the end-of-archive marker with nothing in front of it. Writers that emit nothing at all produce a file most readers reject, which is the bug this 1024-byte file exists to distinguish.

File: TAR · Empty · 0 members
Use case: Conversion testingError handling· Conversion set

TAR - FIFO and Device Node Records

A FIFO, a character device and a block device, each a header with no data blocks and with the device numbers in the devmajor/devminor fields. Unprivileged extraction cannot create the two device nodes, so the correct behaviour is to skip them with a warning rather than to abort the whole archive or to create empty regular files in their place.

File: TAR · Tar Records · 4 members
Use case: Conversion testingError handling+1· Conversion set

TAR - GNU Format

GNU tar's extension of the same header, identified by its own magic: long names get their own 'L' record, oversized numeric fields switch to base-256, and sparse files get an in-header map. All three archives in this group hold byte-identical members with identical ownership and modification times, so any other difference a reader reports between them comes from the header encoding alone.

File: TAR · Tar Format · 3 members
Use case: Conversion testingMetadata testing· Conversion set

TAR - GNU Long Name Record

A 125-character path whose long component contains no slash at all, so the USTAR prefix field cannot store it. This archive uses a preceding 'L' (GNUTYPE_LONGNAME) record whose payload is the full path. Its group siblings encode the same class of path with the other two mechanisms.

File: TAR · Tar Format · 2 members
Use case: Conversion testingError handling· Conversion set

TAR - Hard Link Member

share/backup/records.csv is a hard link to a member that appears earlier in the stream, so its content is stored exactly once. Order matters: a reader that extracts members out of sequence, or that copies content instead of linking, changes both the on-disk byte count and the inode relationship the archive is describing.

File: TAR · Tar Records · 3 members
Use case: Conversion testingMetadata testing· Conversion set

TAR - Large UID/GID (GNU base-256)

The uid and gid fields hold 7 octal digits, so they top out at 2097151. This member is owned by uid 3000000, which needs GNU base-256 encoding: the field's high bit is set and the remaining bytes are a big-endian integer. Its group sibling encodes the same ownership the other way, so a reader can be checked against both without a second variable.

File: TAR · Tar Records · 2 members
Use case: Conversion testingMetadata testing+1· Conversion set

TAR - Large UID/GID (PAX records)

The uid and gid fields hold 7 octal digits, so they top out at 2097151. This member is owned by uid 3000000, which needs PAX uid=/gid= records in an 'x' extended header, with the classic field left at its maximum. Its group sibling encodes the same ownership the other way, so a reader can be checked against both without a second variable.

File: TAR · Tar Records · 2 members
Use case: Conversion testingMetadata testing+1· Conversion set

TAR - Missing End-of-Archive Blocks

A tar that ends immediately after its last member, with none of the two 512-byte zero blocks the format calls for. Plenty of writers do this and GNU tar reads it with a warning; readers that treat a missing end marker as a truncated archive reject three perfectly good members.

File: TAR · Tar Stream · 3 members
Use case: Conversion testingError handling· Conversion set

TAR - Old GNU Sparse File

A 1 MiB file with a 1047552-byte hole in the middle, stored the old GNU way: typeflag 'S' and a four-slot sparse map written into the header block itself. Only 1024 bytes are actually in the stream, so a reader that ignores the map reconstructs a 1024-byte file instead of a 1 MiB one.

File: TAR · Tar Sparse · 2 members
Use case: Conversion testingMetadata testing· Conversion set

TAR - Owner Names Longer Than the Header Field

The uname and gname fields in a tar header are 32 bytes. This archive's second member is owned by a 44-character service-account name, which only fits because PAX moves it into an extended header. A USTAR writer would have truncated it to 31 characters and lost the distinction between two similarly-named accounts.

File: TAR · Tar Records · 2 members
Use case: Conversion testingMetadata testing· Conversion set

TAR - Padded to a 10240-Byte Record

The same three members followed by the end-of-archive blocks and then zero padding out to a whole 10240-byte record - tar's historical blocking factor of 20, still the default. The archive is 10240 bytes for 616 bytes of content, which is what makes tiny tarballs look so wasteful before compression.

File: TAR · Tar Stream · 3 members
Use case: Conversion testingPerformance testing· Conversion set

TAR - PAX Format

The 2001 POSIX format: anything the classic header cannot express moves into an 'x' extended header of UTF-8 key=value records placed immediately before the member it describes. Here each member carries atime and ctime records, which is why this archive is structurally different from its USTAR twin rather than byte-identical to it. All three archives in this group hold byte-identical members with identical ownership and modification times, so any other difference a reader reports between them comes from the header encoding alone.

File: TAR · Tar Format · 3 members
Use case: Conversion testingMetadata testing· Conversion set

Explore the test library

Filter the library

131 results