Next: , Up: (dir)

Tarlz Manual

This manual is for Tarlz (version 0.5, 29 September 2018).


Copyright © 2013-2018 Antonio Diaz Diaz.

This manual is free documentation: you have unlimited permission to copy, distribute and modify it.


Next: , Previous: Top, Up: Top

1 Introduction

Tarlz is a small and simple implementation of the tar archiver. By default tarlz creates, lists and extracts archives in a simplified posix pax format compressed with lzip on a per file basis. Tarlz can append files to the end of such compressed archives.

Each tar member is compressed in its own lzip member, as well as the end-of-file blocks. This same method works for any tar format (gnu, ustar, posix) and is fully backward compatible with standard tar tools like GNU tar, which treat the resulting multimember tar.lz archive like any other tar.lz archive.

Tarlz can create tar archives with four levels of compression granularity; per file, per directory, appendable solid, and solid.

Of course, compressing each file (or each directory) individually is less efficient than compressing the whole tar archive, but it has the following advantages:

Note that the posix pax format has a serious flaw. The metadata stored in pax extended records are not protected by any kind of check sequence. Corruption in a long name may cause the extraction of the file in the wrong place without warning. Corruption in a long size may cause the truncation of the file or the appending of garbage to the file, both followed by a spurious warning about a corrupt header far from the place of the undetected corruption.

Metadata like filename and file size must be always protected in an archive format because of the adverse effects of undetected corruption in them, potentially much worse that undetected corruption in the data. Even more so in the case of pax because the amount of metadata it stores is potentially large, making undetected corruption more probable.

Because of the above, tarlz implements a CRC of the extended records (see crc32) and an option to ignore a missing CRC in archives not created by tarlz (see --ignore-crc).

Tarlz is intended as a showcase project for the maintainers of real tar programs to evaluate the format and perhaps implement it in their tools.


Next: , Previous: Introduction, Up: Top

2 Invoking tarlz

The format for running tarlz is:

     tarlz [options] [files]

On archive creation or appending, tarlz removes leading and trailing slashes from filenames, as well as filename prefixes containing a '..' component. On extraction, archive members containing a '..' component are skipped.

tarlz supports the following options:

-h
--help
Print an informative help message describing the options and exit.
-V
--version
Print the version number of tarlz on the standard output and exit. This version number should be included in all bug reports.
-c
--create
Create a new archive from files.
-C dir
--directory=dir
Change to directory dir. When creating or appending, the position of each -C option in the command line is significant; it will change the current working directory for the following files until a new -C option appears in the command line. When extracting, all the -C options are executed in sequence before starting the extraction. Listing ignores any -C options specified. dir is relative to the then current working directory, perhaps changed by a previous -C option.
-f archive
--file=archive
Use archive file archive. '-' used as an archive argument reads from standard input or writes to standard output.
-q
--quiet
Quiet operation. Suppress all messages.
-r
--append
Append files to the end of an archive. The archive must be a regular (seekable) file compressed as a multimember lzip file, and the two end-of-file blocks plus any zero padding must be contained in the last lzip member of the archive. First this last member is removed, then the new members are appended, and then a new end-of-file member is appended to the archive. Exit with status 0 without modifying the archive if no files have been specified. tarlz can't append files to an uncompressed tar archive.
-t
--list
List the contents of an archive. If files are given, list only the given files.
-v
--verbose
Verbosely list files processed.
-x
--extract
Extract files from an archive. If files are given, extract only the given files. Else extract all the files in the archive.
-0 .. -9
Set the compression level. The default compression level is '-6'.
--asolid
When creating or appending to a compressed archive, use appendable solid compression. All the files being added to the archive are compressed into a single lzip member, but the end-of-file blocks are compressed into a separate lzip member. This creates a solidly compressed appendable archive.
--dsolid
When creating or appending to a compressed archive, use solid compression for each directory especified in the command line. The end-of-file blocks are compressed into a separate lzip member. This creates a compressed appendable archive with a separate lzip member for each top-level directory.
--solid
When creating or appending to a compressed archive, use solid compression. The files being added to the archive, along with the end-of-file blocks, are compressed into a single lzip member. The resulting archive is not appendable. No more files can be later appended to the archive without decompressing it first.
--group=group
When creating or appending, use group for files added to the archive. If group is not a valid group name, it is decoded as a decimal numeric group ID.
--owner=owner
When creating or appending, use owner for files added to the archive. If owner is not a valid user name, it is decoded as a decimal numeric user ID.


--ignore-crc
Ignore a missing CRC in the extended records. Useful when reading an archive not created by tarlz.
--uncompressed
With --create, don't compress the created tar archive. Create an uncompressed tar archive instead.

Exit status: 0 for a normal exit, 1 for environmental problems (file not found, invalid flags, I/O errors, etc), 2 to indicate a corrupt or invalid input file, 3 for an internal consistency error (eg, bug) which caused tarlz to panic.


Next: , Previous: Invoking tarlz, Up: Top

3 File format

In the diagram below, a box like this:

+---+
|   | <-- the vertical bars might be missing
+---+

represents one byte; a box like this:

+==============+
|              |
+==============+

represents a variable number of bytes or a fixed but large number of bytes (for example 512).


A tar.lz file consists of a series of lzip members (compressed data sets). The members simply appear one after another in the file, with no additional information before, between, or after them.

Each lzip member contains one or more tar members in a simplified posix pax interchange format; the only pax typeflag value supported by tarlz (in addition to the typeflag values defined by the ustar format) is 'x'. The pax format is an extension on top of the ustar format that removes the size limitations of the ustar format.

Each tar member contains one file archived, and is represented by the following sequence:

At the end of the archive file there are two 512-byte blocks filled with binary zeros, interpreted as an end-of-archive indicator. These EOF blocks are either compressed in a separate lzip member or compressed along with the tar members contained in the last lzip member.

The diagram below shows the correspondence between each tar member (formed by one or two headers plus optional data) in the tar archive and each lzip member in the resulting multimember tar.lz archive:

tar
+========+======+=================+===============+========+======+========+
| header | data | extended header | extended data | header | data |   eof  |
+========+======+=================+===============+========+======+========+

tar.lz
+===============+=================================================+========+
|     member    |                      member                     | member |
+===============+=================================================+========+

3.1 Pax header block

The pax header block is identical to the ustar header block described below except that the typeflag has the value 'x' (extended). The size field is the size of the extended header data in bytes. The other fields in the pax header block are set on archive creation to values that provide reasonable file access if the archive is read by an ustar tool, and are ignored by tarlz on archive extraction. A difference with posix pax is that tarlz stores (for now) the name field as-is, limited to a length of 100 bytes.

The pax extended header data consists of one or more records, each of them constructed as follows:
"%d %s=%s\n", <length>, <keyword>, <value>

The <length>, <blank>, <keyword>, <equals-sign>, and <newline> in the record must be limited to the portable character set. The <length> field contains the decimal length of the record in bytes, including the trailing <newline>. The <value> field is stored as-is, without conversion to UTF-8 nor any other transformation.

These are the <keyword> fields currently supported by tarlz:

linkpath
The pathname of a link being created to another file, of any type, previously archived. This record overrides the linkname field in the following ustar header block. The following ustar header block determines the type of link created. If typeflag of the following header block is 1, it will be a hard link. If typeflag is 2, it will be a symbolic link and the linkpath value will be used as the contents of the symbolic link.
path
The pathname of the following file. This record overrides the name and prefix fields in the following ustar header block.
size
The size of the file in bytes, expressed as a decimal number using digits from the ISO/IEC 646:1991 (ASCII) standard. This record overrides the size field in the following ustar header block. The size record is used only for files with a size value greater than 8_589_934_591 (octal 77777777777). This is 2^33 bytes or larger.


GNU.crc32
CRC32-C (Castagnoli) of the extended header data excluding the 8 bytes representing the CRC <value> itself. The <value> is represented as 8 hexadecimal digits in big endian order, '22 GNU.crc32=00000000\n'. The keyword of the CRC record needs to be protected to guarante that corruption is always detected (except in case of CRC collision). A CRC was chosen because a checksum is too weak for a potentially large list of variable sized records. A checksum can't detect simple errors like the swapping of two bytes.

3.2 Ustar header block

The ustar header block has a length of 512 bytes and is structured as shown in the following table. All lengths and offsets are in decimal.

Field Name Offset Length (in bytes)
name 0 100
mode 100 8
uid 108 8
gid 116 8
size 124 12
mtime 136 12
chksum 148 8
typeflag 156 1
linkname 157 100
magic 257 6
version 263 2
uname 265 32
gname 297 32
devmajor 329 8
devminor 337 8
prefix 345 155

All characters in the header block are coded using the ISO/IEC 646:1991 (ASCII) standard, except in fields storing names for files, users, and groups. For maximum portability between implementations, names should only contain characters from the portable filename character set. But if an implementation supports the use of characters outside of '/' and the portable filename character set in names for files, users, and groups, tarlz will use the byte values in these names unmodified.

The fields name, linkname, and prefix are null-terminated character strings except when all characters in the array contain non-null characters including the last character.

The name and the prefix fields produce the pathname of the file. A new pathname is formed, if prefix is not an empty string (its first character is not null), by concatenating prefix (up to the first null character), a <slash> character, and name; otherwise, name is used alone. In either case, name is terminated at the first null character. If prefix begins with a null character, it is ignored. In this manner, pathnames of at most 256 characters can be supported. If a pathname does not fit in the space provided, an extended record is used to store the pathname.

The linkname field does not use the prefix to produce a pathname. If the linkname does not fit in the 100 characters provided, an extended record is used to store the linkname.

The mode field provides 12 access permission bits. The following table shows the symbolic name of each bit and its octal value:

Bit Name Bit value
S_ISUID 04000
S_ISGID 02000
S_ISVTX 01000
S_IRUSR 00400
S_IWUSR 00200
S_IXUSR 00100
S_IRGRP 00040
S_IWGRP 00020
S_IXGRP 00010
S_IROTH 00004
S_IWOTH 00002
S_IXOTH 00001

The uid and gid fields are the user and group ID of the owner and group of the file, respectively.

The size field contains the octal representation of the size of the file in bytes. If the typeflag field specifies a file of type '0' (regular file) or '7' (high performance regular file), the number of logical records following the header is (size / 512) rounded to the next integer. For all other values of typeflag, tarlz either sets the size field to 0 or ignores it, and does not store or expect any logical records following the header. If the file size is larger than 8_589_934_591 bytes (octal 77777777777), an extended record is used to store the file size.

The mtime field contains the octal representation of the modification time of the file at the time it was archived, obtained from the stat() function.

The chksum field contains the octal representation of the value of the simple sum of all bytes in the header logical record. Each byte in the header is treated as an unsigned value. When calculating the checksum, the chksum field is treated as if it were all <space> characters.

The typeflag field contains a single character specifying the type of file archived:

'0'
Regular file.
'1'
Hard link to another file, of any type, previously archived.
'2'
Symbolic link.
'3', '4'
Character special file and block special file respectively. In this case the devmajor and devminor fields contain information defining the device in unspecified format.
'5'
Directory.
'6'
FIFO special file.
'7'
Reserved to represent a file to which an implementation has associated some high-performance attribute. Tarlz treats this type of file as a regular file (type 0).

The magic field contains the ASCII null-terminated string "ustar". The version field contains the characters "00" (0x30,0x30). The fields uname, and gname are null-terminated character strings. Each numeric field contains a leading zero-filled, null-terminated octal number using digits from the ISO/IEC 646:1991 (ASCII) standard.


Next: , Previous: File format, Up: Top

4 A small tutorial with examples

Example 1: Create a multimember compressed archive 'archive.tar.lz' containing files 'a', 'b' and 'c'.

     tarlz -cf archive.tar.lz a b c

Example 2: Append files 'd' and 'e' to the multimember compressed archive 'archive.tar.lz'.
     tarlz -rf archive.tar.lz d e

Example 3: Create a solidly compressed appendable archive 'archive.tar.lz' containing files 'a', 'b' and 'c'. Then append files 'd' and 'e' to the archive.
     tarlz --asolid -cf archive.tar.lz a b c
     tarlz --asolid -rf archive.tar.lz d e

Example 4: Create a compressed appendable archive containing directories 'dir1', 'dir2' and 'dir3' with a separate lzip member per directory. Then append files 'a', 'b', 'c', 'd' and 'e' to the archive, all of them contained in a single lzip member. The resulting archive 'archive.tar.lz' contains 5 lzip members (including the eof member).
     tarlz --dsolid -cf archive.tar.lz dir1 dir2 dir3
     tarlz --asolid -rf archive.tar.lz a b c d e

Example 5: Create a solidly compressed archive 'archive.tar.lz' containing files 'a', 'b' and 'c'. Note that no more files can be later appended to the archive without decompressing it first.
     tarlz --solid -cf archive.tar.lz a b c

Example 6: Extract all files from archive 'archive.tar.lz'.
     tarlz -xf archive.tar.lz

Example 7: Extract files 'a' and 'c' from archive 'archive.tar.lz'.
     tarlz -xf archive.tar.lz a c

Example 8: Copy the contents of directory 'sourcedir' to the directory 'targetdir'.
     tarlz -C sourcedir -c . | tarlz -C targetdir -x


Next: , Previous: Examples, Up: Top

5 Reporting bugs

There are probably bugs in tarlz. There are certainly errors and omissions in this manual. If you report them, they will get fixed. If you don't, no one will ever know about them and they will remain unfixed for all eternity, if not longer.

If you find a bug in tarlz, please send electronic mail to lzip-bug@nongnu.org. Include the version number, which you can find by running tarlz --version.


Previous: Problems, Up: Top

Concept index