TGZ to TXT — a manifest of a compressed bundle for an inventory review
An inventory review needs to record what a bundle carries, and a compressed tarball is awkward to read by hand. This route unwinds the gzip stream inside the browser tab, lists the tar members and writes a plain manifest of names, kinds and uncompressed byte counts. Payloads are not unpacked, nothing is uploaded, and a manifest that runs too long says so instead of stopping quietly.
tar mode bits, owner and group names are not carried into ZIP; directories are written as empty entries.
Processed on your device. Files aren’t sent anywhere.
Recording a compressed bundle in a note
The reviewer's question is structural: does the bundle carry the directories it should, and does it carry anything it should not? A manifest answers that without anyone unpacking the archive.
An inventory comparison is about structure and size, not about what the files say.
The scope of a listing route
Review note questions
Does the manifest contain the files' contents?
Can I quote a truncated manifest as complete?
Why did a bundle that opens fine elsewhere get rejected?
Does the manifest keep the gzip header name or date?
Are the byte figures compressed sizes or unpacked sizes?
What each line says
Three fields per entry, in archive order by default or sorted by name when the note needs an alphabetical manifest.
- name — the path stored inside the tar, after the gzip wrapper is unwound.
- kind — file or directory.
- bytes — the uncompressed payload length, not the size inside the gzip stream.
- The gzip header's stored filename and timestamp are not carried into the manifest.
- Unsupported entries stop the read with a named error rather than appearing as blank rows.
A listing is not the decompressed payload
For a container such as a tar.gz, the text output is a manifest of entries. It is not the contents of any member and it is not a single decompressed stream.
A gzip stream holding one text file is a different job: that route returns the decompressed text itself. Confusing the two produces a note that quotes a file list where a document was expected, or the reverse.
Producing the manifest
- Load the .tar.gz or .tgz into the studio; one file, ceiling 12 MiB, and the read stays in the browser.
- Set the target to TXT.
- Pick entry order: archive order by default, sorted by name for an alphabetical note.
- Let the gzip layer and the tar beneath it finish; 200 entries maximum and 8 MiB for any member.
- Paste the manifest into the review note, checking for a truncation marker first.
- If the bundle is rejected, the file list reports the rejection reason; it may not identify the individual member.
Bounds that shape the manifest
The listing stops at 200000 characters and appends a marker when truncated, so a partial manifest is visibly partial.
- The gunzipped TAR stream, including headers and padding, is capped at 32 MiB and a 60x ratio. File payload bounds apply in addition.
- Symlink, hardlink, device and FIFO entries and PAX or GNU extended headers are refused.
- Absolute, traversal and duplicate paths are refused, as are non-UTF8 names.
- USTAR fields have fixed byte widths; PAX/GNU extension records are refused. The reader cannot identify or restore a name already truncated by the archive producer.
- The listing does not extract members to folders, restore timestamps or permissions, or identify malware.