Convert TAR.LZO to TAR Online (Removing the Speed-Optimized Compression Layer)

A TAR.LZO File Was Always a Tar File, Just Wrapped for Speed

Converting a TAR.LZO file into a plain TAR isn't a conversion between two archive designs at all — it's removing a single compression layer that lzop applied on top of an ordinary tar file to begin with. Tar itself, standardized under POSIX since 1988, packs each file into a 512-byte header block recording its name, owner, group, permission mode, and size, followed by that file's raw data padded to the next 512-byte boundary, ending with two consecutive zero-filled 512-byte blocks marking the archive's end. Lzop's LZO compression, built around Markus Oberhumer's library and first released as a tool on August 10, 1997, runs entirely independently on top of whatever byte stream tar produces, with no awareness of the file boundaries inside it.

Because those two jobs never overlap, undoing a TAR.LZO back into plain TAR is a single, fully reversible operation: decompress lzop's LZO-compressed blocks, and the exact tar byte sequence that existed before compression comes back out completely unchanged — file order, header contents, padding, and the trailing zero blocks are all restored precisely as tar originally wrote them.

Why the Resulting File Grows, and Why LZO Made That Trade on Purpose

Removing LZO's compression is the one part of this conversion that isn't neutral: the resulting plain tar file is always larger than the TAR.LZO it came from, since shrinking that byte stream was the whole reason lzop compressed it in the first place. How much larger depends on how compressible the original content was and which LZO method built the archive — lzop's default lzo1x_1 method, or the considerably more thorough lzo1x_999 method invoked with --best, both leave more redundancy in their compressed output than a heavier algorithm like gzip's DEFLATE or bzip2 would, precisely because LZO deliberately skips the entropy-coding stage those algorithms both add.

Nothing about tar's own internal structure changes during this step. Every 512-byte header stays exactly as GNU tar or whichever implementation originally wrote it, and lzop's own per-block Adler-32 or CRC-32 checksums — used specifically to detect, not repair, corruption in individual compressed blocks — simply disappear once decompression is complete, since a plain tar file has no compression-layer checksum of its own at all beyond tar's own per-header checksum field.

Any long-filename or sparse-file extensions present before compression also decompress along with everything else and remain fully intact and readable by any tar implementation that already supported them — GNU tar's own extensions or the pax interchange format defined in IEEE Std 1003.1-2001 both survive this step exactly as they were, since neither depends in any way on which compressor was wrapped around the finished tar stream.

What Stripping Off LZO's Speed-Optimized Layer Gains and Trades Away

• Gain — a format some downstream pipelines specifically expect uncompressed: certain backup, deduplication, or re-compression tools need a plain tar file as their input.
• Gain — direct in-place editing: GNU tar's --delete or --append options work against an uncompressed tar file, not a compressed stream, since those operations need random access to the archive structure.
• Lose — LZO's fast decompression benefit going forward: a plain tar file offers nothing to decompress at all, so the speed advantage that made LZO worth choosing no longer applies to this specific copy.
• Lose — the smaller file size LZO provided: the plain tar is always at least as large as, and usually noticeably larger than, the original TAR.LZO.
• Unchanged — every file's Unix permissions, ownership, and name: tar's own header fields decompress exactly as written, untouched by this step.
• Lose — lzop's per-block checksums: a plain tar file carries no equivalent compressed-block integrity check of its own.

Which Tools Can Actually Perform This Specific Decompression

Decompressing a TAR.LZO file requires the lzop utility specifically, or GNU tar used with its --lzop flag pointed at an installed lzop binary, since mainstream Windows and macOS archive tools, including 7-Zip and WinRAR, generally don't include native LZO decompression at all. Lzop itself is packaged for essentially every mainstream Linux distribution, making this decompression step straightforward on the platforms where TAR.LZO files are actually produced in the first place.

Once lzop or GNU tar's --lzop flag has decompressed the LZO layer, the resulting plain tar file behaves identically to any other tar archive: GNU tar, BSD tar, and every mainstream archive tool on any platform can read, list, and extract it without needing to know anything about LZO at all, since the compression-specific step has already been completed before the plain tar file exists.

This is also why a plain, decompressed tar file makes a convenient intermediate format for cross-platform sharing in a pinch: while a colleague on Windows might not have lzop installed to read a TAR.LZO directly, an already-decompressed .tar file opens in 7-Zip, WinRAR, or PeaZip without any LZO-specific support needed at all, at the cost of the larger file size that decompression produces.

The Real, Documented Reasons Someone Strips LZO Compression Off

A common scenario involves recompressing the same underlying tar content with a different, tighter algorithm entirely — someone who wants a TAR.GZ, TAR.BZ2, or 7z archive instead of TAR.LZO has to decompress back to plain tar first as an intermediate step, since those target formats need the raw tar stream as their input rather than one already compressed with LZO's specific block structure.

A second real pattern involves examining or modifying an archive's contents entry by entry, which GNU tar's in-place --delete or --append options only support against an uncompressed tar file, not a compressed stream, since those operations require random access to the archive's internal structure that LZO's compressed blocks don't offer in the same direct way.

A third scenario shows up specifically in embedded-systems development, where a firmware image originally built as TAR.LZO for fast on-device decompression needs to be inspected or modified on a development workstation using tools that only understand plain tar directly, without the extra step of installing lzop specifically for that one task — decompressing once at the start of the workflow avoids needing LZO support at every later stage.

A fourth pattern involves storage or transfer paths that already apply their own compression at a lower level, such as certain network filesystems or storage arrays with built-in block-level compression — compressing the data twice, once with LZO and again with the storage layer's own scheme, adds CPU overhead without meaningfully shrinking the result further, so decompressing back to plain tar before the transfer avoids paying that redundant cost twice.

Compressed TAR.LZO Set Against the Plain TAR It Decompresses Into

Common Questions About Turning a TAR.LZO Back Into Plain TAR

Why would I want a bigger, uncompressed file instead of the smaller TAR.LZO?
Some downstream tools, like a different recompressor or an entry-editing tool, specifically need uncompressed input, since compressing twice or editing a compressed stream in place doesn't work the same way as with plain tar.

Does decompressing a TAR.LZO change any of the files inside it?
No. LZO is lossless, and tar's own header structure is untouched by compression entirely, so every file, permission, and name comes back exactly as it was before the TAR.LZO was created.

Why is the plain TAR file bigger than the TAR.LZO was?
Because LZO's whole purpose was shrinking that data. LZO also compresses less tightly than gzip or bzip2 to begin with, since it skips their entropy-coding stage, so the size increase can be more noticeable than with those other formats.

Can I add or remove files from a TAR.LZO directly, without decompressing it first?
Not with GNU tar's in-place --delete or --append options — those require an uncompressed tar file, since editing a compressed stream in place isn't structurally supported the same way.

Do lzop's per-block checksums carry over into the plain tar file?
No. Those checksums exist specifically to protect the compressed data during transport or storage; once decompression is complete, they've done their job and a plain tar file has no equivalent of its own.

Is a decompressed TAR.LZO file the same as one built directly as plain TAR from scratch?
Yes. Once lzop's compression layer is removed, the resulting bytes are an ordinary tar archive indistinguishable from one tar wrote without any compression step involved at all.

Will decompressing take long on a large TAR.LZO file?
Generally not, since LZO's own design goal is fast decompression above nearly everything else, so this specific step tends to run quicker than the equivalent decompression of a gzip- or bzip2-based archive of similar size.