Adding upstream version 0.17.upstream/0.17

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

3 files changed, 815 insertions, 593 deletions

diff --git a/doc/tarlz.1 b/doc/tarlz.1
index 83325dd..cf0f659 100644
--- a/doc/tarlz.1
+++ b/doc/tarlz.1
@@ -1,5 +1,5 @@
 .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.46.1.
-.TH TARLZ "1" "October 2019" "tarlz 0.16" "User Commands"
+.TH TARLZ "1" "July 2020" "tarlz 0.17" "User Commands"
 .SH NAME
 tarlz \- creates tar archives with multimember lzip compression
 .SH SYNOPSIS
@@ -64,9 +64,15 @@ use archive file <archive>
 \fB\-h\fR, \fB\-\-dereference\fR
 follow symlinks; archive the files they point to
 .TP
+\fB\-\-mtime=\fR<date>
+use <date> as mtime for files added to archive
+.TP
 \fB\-n\fR, \fB\-\-threads=\fR<n>
 set number of (de)compression threads [2]
 .TP
+\fB\-p\fR, \fB\-\-preserve\-permissions\fR
+don't subtract the umask on extraction
+.TP
 \fB\-q\fR, \fB\-\-quiet\fR
 suppress all messages
 .TP
@@ -107,10 +113,10 @@ create solidly compressed archive
 equivalent to '\-\-owner=root \fB\-\-group\fR=\fI\,root\/\fR'
 .TP
 \fB\-\-owner=\fR<owner>
-use <owner> name/ID for files added
+use <owner> name/ID for files added to archive
 .TP
 \fB\-\-group=\fR<group>
-use <group> name/ID for files added
+use <group> name/ID for files added to archive
 .TP
 \fB\-\-keep\-damaged\fR
 don't delete partially extracted files
@@ -121,17 +127,17 @@ exit with error status if missing extended CRC
 \fB\-\-out\-slots=\fR<n>
 number of 1 MiB output packets buffered [64]
 .PP
-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.
+Exit status: 0 for a normal exit, 1 for environmental problems (file not
+found, files differ, 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.
 .SH "REPORTING BUGS"
 Report bugs to lzip\-bug@nongnu.org
 .br
 Tarlz home page: http://www.nongnu.org/lzip/tarlz.html
 .SH COPYRIGHT
-Copyright \(co 2019 Antonio Diaz Diaz.
-Using lzlib 1.11
+Copyright \(co 2020 Antonio Diaz Diaz.
+Using lzlib 1.12\-rc1a
 License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
 .br
 This is free software: you are free to change and redistribute it.
diff --git a/doc/tarlz.info b/doc/tarlz.info
index edcee44..e2c61db 100644
--- a/doc/tarlz.info
+++ b/doc/tarlz.info
@@ -11,7 +11,7 @@ File: tarlz.info,  Node: Top,  Next: Introduction,  Up: (dir)
 Tarlz Manual
 ************
 
-This manual is for Tarlz (version 0.16, 8 October 2019).
+This manual is for Tarlz (version 0.17, 30 July 2020).
 
 * Menu:
 
@@ -20,17 +20,18 @@ This manual is for Tarlz (version 0.16, 8 October 2019).
 * Portable character set::    POSIX portable filename character set
 * File format::               Detailed format of the compressed archive
 * Amendments to pax format::  The reasons for the differences with pax
-* Multi-threaded tar::        Limitations of parallel tar decoding
+* Program design::            Internal structure of tarlz
+* Multi-threaded decoding::   Limitations of parallel tar decoding
 * Minimum archive sizes::     Sizes required for full multi-threaded speed
 * Examples::                  A small tutorial with examples
 * Problems::                  Reporting bugs
 * Concept index::             Index of concepts
 
 
-   Copyright (C) 2013-2019 Antonio Diaz Diaz.
+   Copyright (C) 2013-2020 Antonio Diaz Diaz.
 
    This manual is free documentation: you have unlimited permission to
-copy, distribute and modify it.
+copy, distribute, and modify it.
 
 
 File: tarlz.info,  Node: Introduction,  Next: Invoking tarlz,  Prev: Top,  Up: Top
@@ -38,25 +39,26 @@ File: tarlz.info,  Node: Introduction,  Next: Invoking tarlz,  Prev: Top,  Up: T
 1 Introduction
 **************
 
-Tarlz is a massively parallel (multi-threaded) combined implementation
-of the tar archiver and the lzip compressor. Tarlz creates, lists and
-extracts archives in a simplified and safer variant of the POSIX pax
-format compressed with lzip, keeping the alignment between tar members
-and lzip members. The resulting multimember tar.lz archive is fully
-backward compatible with standard tar tools like GNU tar, which treat
-it like any other tar.lz archive. Tarlz can append files to the end of
-such compressed archives.
+Tarlz is a massively parallel (multi-threaded) combined implementation of
+the tar archiver and the lzip compressor. Tarlz creates, lists and extracts
+archives in a simplified and safer variant of the POSIX pax format
+compressed with lzip, keeping the alignment between tar members and lzip
+members. The resulting multimember tar.lz archive is fully backward
+compatible with standard tar tools like GNU tar, which treat it like any
+other tar.lz archive. Tarlz can append files to the end of such compressed
+archives.
 
    Keeping the alignment between tar members and lzip members has two
-advantages. It adds an indexed lzip layer on top of the tar archive,
-making it possible to decode the archive safely in parallel. It also
-minimizes the amount of data lost in case of corruption. Compressing a
-tar archive with plzip may even double the amount of files lost for
-each lzip member damaged because it does not keep the members aligned.
+advantages. It adds an indexed lzip layer on top of the tar archive, making
+it possible to decode the archive safely in parallel. It also minimizes the
+amount of data lost in case of corruption. Compressing a tar archive with
+plzip may even double the amount of files lost for each lzip member damaged
+because it does not keep the members aligned.
 
    Tarlz can create tar archives with five levels of compression
 granularity; per file (--no-solid), per block (--bsolid, default), per
-directory (--dsolid), appendable solid (--asolid), and solid (--solid).
+directory (--dsolid), appendable solid (--asolid), and solid (--solid). It
+can also create uncompressed tar archives.
 
 Of course, compressing each file (or each directory) individually can't
 achieve a compression ratio as high as compressing solidly the whole tar
@@ -69,22 +71,22 @@ archive, but it has the following advantages:
      member), and unwanted members can be deleted from the archive. Just
      like an uncompressed tar archive.
 
-   * It is a safe POSIX-style backup format. In case of corruption,
-     tarlz can extract all the undamaged members from the tar.lz
-     archive, skipping over the damaged members, just like the standard
-     (uncompressed) tar. Moreover, the option '--keep-damaged' can be
-     used to recover as much data as possible from each damaged member,
-     and lziprecover can be used to recover some of the damaged members.
+   * It is a safe POSIX-style backup format. In case of corruption, tarlz
+     can extract all the undamaged members from the tar.lz archive,
+     skipping over the damaged members, just like the standard
+     (uncompressed) tar. Moreover, the option '--keep-damaged' can be used
+     to recover as much data as possible from each damaged member, and
+     lziprecover can be used to recover some of the damaged members.
 
-   * A multimember tar.lz archive is usually smaller than the
-     corresponding solidly compressed tar.gz archive, except when
-     individually compressing files smaller than about 32 KiB.
+   * A multimember tar.lz archive is usually smaller than the corresponding
+     solidly compressed tar.gz archive, except when compressing files
+     smaller than about 32 KiB individually.
 
-   Tarlz protects the extended records with a CRC in a way compatible
-with standard tar tools. *Note crc32::.
+   Tarlz protects the extended records with a Cyclic Redundancy Check (CRC)
+in a way compatible with standard tar tools. *Note crc32::.
 
-   Tarlz does not understand other tar formats like 'gnu', 'oldgnu',
-'star' or 'v7'. 'tarlz -tf archive.tar.lz > /dev/null' can be used to
+   Tarlz does not understand other tar formats like 'gnu', 'oldgnu', 'star'
+or 'v7'. The command 'tarlz -tf archive.tar.lz > /dev/null' can be used to
 verify that the format of the archive is compatible with tarlz.
 
 
@@ -97,27 +99,28 @@ The format for running tarlz is:
 
      tarlz [OPTIONS] [FILES]
 
-All operations except '--concatenate' operate on whole trees if any
-FILE is a directory.
+All operations except '--concatenate' operate on whole trees if any FILE is
+a directory.
 
-   On archive creation or appending tarlz archives the files specified,
-but removes from member names any leading and trailing slashes and any
-file name prefixes containing a '..' component. On extraction, leading
-and trailing slashes are also removed from member names, and archive
-members containing a '..' component in the file name are skipped. Tarlz
-detects when the archive being created or enlarged is among the files
-to be dumped, appended or concatenated, and skips it.
+   On archive creation or appending tarlz archives the files specified, but
+removes from member names any leading and trailing slashes and any file name
+prefixes containing a '..' component. On extraction, leading and trailing
+slashes are also removed from member names, and archive members containing
+a '..' component in the file name are skipped. Tarlz detects when the
+archive being created or enlarged is among the files to be dumped, appended
+or concatenated, and skips it.
 
    On extraction and listing, tarlz removes leading './' strings from
 member names in the archive or given in the command line, so that
-'tarlz -xf foo ./bar baz' extracts members 'bar' and './baz' from
-archive 'foo'.
+'tarlz -xf foo ./bar baz' extracts members 'bar' and './baz' from archive
+'foo'.
 
-   If several compression levels or '--*solid' options are given, the
-last setting is used. For example '-9 --solid --uncompressed -1' is
-equivalent to '-1 --solid'
+   If several compression levels or '--*solid' options are given, the last
+setting is used. For example '-9 --solid --uncompressed -1' is equivalent
+to '-1 --solid'
 
-   tarlz supports the following options:
+   tarlz supports the following options: *Note Argument syntax:
+(arg_parser)Argument syntax.
 
 '--help'
      Print an informative help message describing the options and exit.
@@ -129,24 +132,23 @@ equivalent to '-1 --solid'
 
 '-A'
 '--concatenate'
-     Append one or more archives to the end of an archive. All the
-     archives involved must be regular (seekable) files, and must be
-     either all compressed or all uncompressed. Compressed and
-     uncompressed archives can't be mixed.  Compressed archives must be
-     multimember lzip files with the two end-of-file blocks plus any
-     zero padding contained in the last lzip member of each archive.
-     The intermediate end-of-file blocks are removed as each new archive
-     is concatenated. If the archive is uncompressed, tarlz parses and
-     skips tar headers until it finds the end-of-file blocks. Exit with
-     status 0 without modifying the archive if no FILES have been
-     specified.
+     Append one or more archives to the end of an archive. All the archives
+     involved must be regular (seekable) files, and must be either all
+     compressed or all uncompressed. Compressed and uncompressed archives
+     can't be mixed. Compressed archives must be multimember lzip files
+     with the two end-of-file blocks plus any zero padding contained in the
+     last lzip member of each archive. The intermediate end-of-file blocks
+     are removed as each new archive is concatenated. If the archive is
+     uncompressed, tarlz parses and skips tar headers until it finds the
+     end-of-file blocks. Exit with status 0 without modifying the archive
+     if no FILES have been specified.
 
 '-B BYTES'
 '--data-size=BYTES'
-     Set target size of input data blocks for the '--bsolid' option.
-     *Note --bsolid::. Valid values range from 8 KiB to 1 GiB. Default
-     value is two times the dictionary size, except for option '-0'
-     where it defaults to 1 MiB. *Note Minimum archive sizes::.
+     Set target size of input data blocks for the option '--bsolid'. *Note
+     --bsolid::. Valid values range from 8 KiB to 1 GiB. Default value is
+     two times the dictionary size, except for option '-0' where it
+     defaults to 1 MiB. *Note Minimum archive sizes::.
 
 '-c'
 '--create'
@@ -154,90 +156,104 @@ equivalent to '-1 --solid'
 
 '-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 or
-     comparing, all the '-C' options are executed in sequence before
-     reading the archive. Listing ignores any '-C' options specified.
-     DIR is relative to the then current working directory, perhaps
-     changed by a previous '-C' option.
-
-     Note that a process can only have one current working directory
-     (CWD).  Therefore multi-threading can't be used to create an
-     archive if a '-C' option appears after a relative file name in the
-     command line.
+     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 or comparing, all
+     the '-C' options are executed in sequence before reading the archive.
+     Listing ignores any '-C' options specified. DIR is relative to the
+     then current working directory, perhaps changed by a previous '-C'
+     option.
+
+     Note that a process can only have one current working directory (CWD).
+     Therefore multi-threading can't be used to create an archive if a '-C'
+     option appears after a relative file name in the command line.
 
 '-d'
 '--diff'
-     Compare and report differences between archive and file system.
-     For each tar member in the archive, verify that the corresponding
-     file in the file system exists and is of the same type (regular
-     file, directory, etc). Report on standard output the differences
-     found in type, mode (permissions), owner and group IDs,
-     modification time, file size, file contents (of regular files),
-     target (of symlinks) and device number (of block/character special
-     files).
-
-     As tarlz removes leading slashes from member names, the '-C'
-     option may be used in combination with '--diff' when absolute file
-     names were used on archive creation: 'tarlz -C / -d'.
-     Alternatively, tarlz may be run from the root directory to perform
-     the comparison.
+     Compare and report differences between archive and file system. For
+     each tar member in the archive, verify that the corresponding file in
+     the file system exists and is of the same type (regular file,
+     directory, etc). Report on standard output the differences found in
+     type, mode (permissions), owner and group IDs, modification time, file
+     size, file contents (of regular files), target (of symlinks) and
+     device number (of block/character special files).
+
+     As tarlz removes leading slashes from member names, the option '-C' may
+     be used in combination with '--diff' when absolute file names were used
+     on archive creation: 'tarlz -C / -d'. Alternatively, tarlz may be run
+     from the root directory to perform the comparison.
 
 '--ignore-ids'
-     Make '--diff' ignore differences in owner and group IDs. This
-     option is useful when comparing an '--anonymous' archive.
+     Make '--diff' ignore differences in owner and group IDs. This option is
+     useful when comparing an '--anonymous' archive.
 
 '--delete'
-     Delete the specified files and directories from an archive in
-     place. It currently can delete only from uncompressed archives and
-     from archives with individually compressed files ('--no-solid'
-     archives). Note that files of about '--data-size' or larger are
-     compressed individually even if '--bsolid' is used, and can
-     therefore be deleted. Tarlz takes care to not delete a tar member
-     unless it is possible to do so. For example it won't try to delete
-     a tar member that is not individually compressed. To delete a
-     directory without deleting the files under it, use
-     'tarlz --delete -f foo --exclude='dir/*' dir'. Deleting in place
-     may be dangerous. A corrupt archive, a power cut, or an I/O error
-     may cause data loss.
+     Delete files and directories from an archive in place. It currently can
+     delete only from uncompressed archives and from archives with files
+     compressed individually ('--no-solid' archives). Note that files of
+     about '--data-size' or larger are compressed individually even if
+     '--bsolid' is used, and can therefore be deleted. Tarlz takes care to
+     not delete a tar member unless it is possible to do so. For example it
+     won't try to delete a tar member that is not compressed individually.
+     Even in the case of finding a corrupt member after having deleted some
+     member(s), tarlz stops and copies the rest of the file as soon as
+     corruption is found, leaving it just as corrupt as it was, but not
+     worse.
+
+     To delete a directory without deleting the files under it, use
+     'tarlz --delete -f foo --exclude='dir/*' dir'. Deleting in place may
+     be dangerous. A corrupt archive, a power cut, or an I/O error may cause
+     data loss.
 
 '--exclude=PATTERN'
-     Exclude files matching a shell pattern like '*.o'. A file is
-     considered to match if any component of the file name matches. For
-     example, '*.o' matches 'foo.o', 'foo.o/bar' and 'foo/bar.o'. If
-     PATTERN contains a '/', it matches a corresponding '/' in the file
-     name. For example, 'foo/*.o' matches 'foo/bar.o'.
+     Exclude files matching a shell pattern like '*.o'. A file is considered
+     to match if any component of the file name matches. For example, '*.o'
+     matches 'foo.o', 'foo.o/bar' and 'foo/bar.o'. If PATTERN contains a
+     '/', it matches a corresponding '/' in the file name. For example,
+     'foo/*.o' matches 'foo/bar.o'.
 
 '-f ARCHIVE'
 '--file=ARCHIVE'
-     Use archive file ARCHIVE. '-' used as an ARCHIVE argument reads
-     from standard input or writes to standard output.
+     Use archive file ARCHIVE. A hyphen '-' used as an ARCHIVE argument
+     reads from standard input or writes to standard output.
 
 '-h'
 '--dereference'
-     Follow symbolic links during archive creation, appending or
-     comparison.  Archive or compare the files they point to instead of
-     the links themselves.
+     Follow symbolic links during archive creation, appending or comparison.
+     Archive or compare the files they point to instead of the links
+     themselves.
+
+'--mtime=DATE'
+     When creating or appending, use DATE as the modification time for
+     files added to the archive instead of their actual modification times.
+     The value of DATE may be either '@' followed by the number of seconds
+     since the epoch, or a date in format 'YYYY-MM-DD HH:MM:SS', or the
+     name of an existing file starting with '.' or '/'. In the latter case,
+     the modification time of that file is used.
 
 '-n N'
 '--threads=N'
      Set the number of (de)compression threads, overriding the system's
-     default.  Valid values range from 0 to "as many as your system can
-     support". A value of 0 disables threads entirely. If this option
-     is not used, tarlz tries to detect the number of processors in the
-     system and use it as default value.  'tarlz --help' shows the
-     system's default value. See the note about multi-threaded archive
-     creation in the '-C' option above.  Multi-threaded extraction of
-     files from an archive is not yet implemented.  *Note
-     Multi-threaded tar::.
-
-     Note that the number of usable threads is limited during
-     compression to ceil( uncompressed_size / data_size ) (*note
-     Minimum archive sizes::), and during decompression to the number
-     of lzip members in the tar.lz archive, which you can find by
-     running 'lzip -lv archive.tar.lz'.
+     default. Valid values range from 0 to "as many as your system can
+     support". A value of 0 disables threads entirely. If this option is
+     not used, tarlz tries to detect the number of processors in the system
+     and use it as default value. 'tarlz --help' shows the system's default
+     value. See the note about multi-threaded archive creation in the
+     option '-C' above. Multi-threaded extraction of files from an archive
+     is not yet implemented. *Note Multi-threaded decoding::.
+
+     Note that the number of usable threads is limited during compression to
+     ceil( uncompressed_size / data_size ) (*note Minimum archive sizes::),
+     and during decompression to the number of lzip members in the tar.lz
+     archive, which you can find by running 'lzip -lv archive.tar.lz'.
+
+'-p'
+'--preserve-permissions'
+     On extraction, set file permissions as they appear in the archive.
+     This is the default behavior when tarlz is run by the superuser. The
+     default for other users is to subtract the umask of the user running
+     tarlz from the permissions specified in the archive.
 
 '-q'
 '--quiet'
@@ -245,20 +261,18 @@ equivalent to '-1 --solid'
 
 '-r'
 '--append'
-     Append files to the end of an archive. The archive must be a
-     regular (seekable) file either compressed or uncompressed.
-     Compressed members can't be appended to an uncompressed archive,
-     nor vice versa. If the archive is compressed, it must be a
-     multimember lzip file with the two end-of-file blocks plus any
-     zero padding contained in the last lzip member of the archive. It
-     is possible to append files to an archive with a different
-     compression granularity. Appending works as follows; first the
-     end-of-file blocks are removed, then the new members are appended,
-     and finally two new end-of-file blocks are appended to the
-     archive. If the archive is uncompressed, tarlz parses and skips
-     tar headers until it finds the end-of-file blocks. Exit with
-     status 0 without modifying the archive if no FILES have been
-     specified.
+     Append files to the end of an archive. The archive must be a regular
+     (seekable) file either compressed or uncompressed. Compressed members
+     can't be appended to an uncompressed archive, nor vice versa. If the
+     archive is compressed, it must be a multimember lzip file with the two
+     end-of-file blocks plus any zero padding contained in the last lzip
+     member of the archive. It is possible to append files to an archive
+     with a different compression granularity. Appending works as follows;
+     first the end-of-file blocks are removed, then the new members are
+     appended, and finally two new end-of-file blocks are appended to the
+     archive. If the archive is uncompressed, tarlz parses and skips tar
+     headers until it finds the end-of-file blocks. Exit with status 0
+     without modifying the archive if no FILES have been specified.
 
 '-t'
 '--list'
@@ -272,15 +286,18 @@ equivalent to '-1 --solid'
 '-x'
 '--extract'
      Extract files from an archive. If FILES are given, extract only the
-     FILES given. Else extract all the files in the archive. To extract
-     a directory without extracting the files under it, use
-     'tarlz -xf foo --exclude='dir/*' dir'.
+     FILES given. Else extract all the files in the archive. To extract a
+     directory without extracting the files under it, use
+     'tarlz -xf foo --exclude='dir/*' dir'. Tarlz will not make any special
+     effort to extract a file over an incompatible type of file. For
+     example, extracting a link over a directory will usually fail.
+     (Principle of least surprise).
 
 '-0 .. -9'
-     Set the compression level for '--create' and '--append'. The
-     default compression level is '-6'. Like lzip, tarlz also minimizes
-     the dictionary size of the lzip members it creates, reducing the
-     amount of memory required for decompression.
+     Set the compression level for '--create' and '--append'. The default
+     compression level is '-6'. Like lzip, tarlz also minimizes the
+     dictionary size of the lzip members it creates, reducing the amount of
+     memory required for decompression.
 
      Level   Dictionary size   Match length limit
      -0      64 KiB            16 bytes
@@ -296,95 +313,94 @@ equivalent to '-1 --solid'
 
 '--uncompressed'
      With '--create', don't compress the tar archive created. Create an
-     uncompressed tar archive instead. With '--append', don't compress
-     the new members appended to the tar archive. Compressed members
-     can't be appended to an uncompressed archive, nor vice versa.
+     uncompressed tar archive instead. With '--append', don't compress the
+     new members appended to the tar archive. Compressed members can't be
+     appended to an uncompressed archive, nor vice versa.
 
 '--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.  Solid archives can't be created
-     nor decoded in parallel.
+     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. Solid archives can't be created nor
+     decoded in parallel.
 
 '--bsolid'
      When creating or appending to a compressed archive, use block
-     compression.  Tar members are compressed together in a lzip member
-     until they approximate a target uncompressed size. The size can't
-     be exact because each solidly compressed data block must contain
-     an integer number of tar members. Block compression is the default
+     compression. Tar members are compressed together in a lzip member
+     until they approximate a target uncompressed size. The size can't be
+     exact because each solidly compressed data block must contain an
+     integer number of tar members. Block compression is the default
      because it improves compression ratio for archives with many files
      smaller than the block size. This option allows tarlz revert to
-     default behavior if, for example, it is invoked through an alias
-     like 'tar='tarlz --solid''. *Note --data-size::, to set the target
-     block size.
+     default behavior if, for example, it is invoked through an alias like
+     'tar='tarlz --solid''. *Note --data-size::, to set the target block
+     size.
 
 '--dsolid'
-     When creating or appending to a compressed archive, compress each
-     file specified in the command line separately in its own lzip
-     member, and use solid compression for each directory specified 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 file or top-level directory
-     specified.
+     When creating or appending to a compressed archive, compress each file
+     specified in the command line separately in its own lzip member, and
+     use solid compression for each directory specified 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 file or top-level directory specified.
 
 '--no-solid'
-     When creating or appending to a compressed archive, compress each
-     file separately in its own lzip member. The end-of-file blocks are
+     When creating or appending to a compressed archive, compress each file
+     separately in its own lzip member. The end-of-file blocks are
      compressed into a separate lzip member. This creates a compressed
      appendable archive with a lzip member for each file.
 
 '--solid'
      When creating or appending to a compressed archive, use solid
-     compression.  The files being added to the archive, along with the
+     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. Solid archives can't be created nor
-     decoded in parallel.
+     appended to the archive. Solid archives can't be created nor decoded
+     in parallel.
 
 '--anonymous'
      Equivalent to '--owner=root --group=root'.
 
 '--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.
+     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.
 
 '--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.
+     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.
 
 '--keep-damaged'
      Don't delete partially extracted files. If a decompression error
-     happens while extracting a file, keep the partial data extracted.
-     Use this option to recover as much data as possible from each
-     damaged member.
+     happens while extracting a file, keep the partial data extracted. Use
+     this option to recover as much data as possible from each damaged
+     member.
 
 '--missing-crc'
-     Exit with error status 2 if the CRC of the extended records is
-     missing.  When this option is used, tarlz detects any corruption
-     in the extended records (only limited by CRC collisions). But note
-     that a corrupt 'GNU.crc32' keyword, for example 'GNU.crc33', is
-     reported as a missing CRC instead of as a corrupt record. This
-     misleading 'Missing CRC' message is the consequence of a flaw in
-     the POSIX pax format; i.e., the lack of a mandatory check sequence
-     in the extended records. *Note crc32::.
+     Exit with error status 2 if the CRC of the extended records is missing.
+     When this option is used, tarlz detects any corruption in the extended
+     records (only limited by CRC collisions). But note that a corrupt
+     'GNU.crc32' keyword, for example 'GNU.crc33', is reported as a missing
+     CRC instead of as a corrupt record. This misleading 'Missing CRC'
+     message is the consequence of a flaw in the POSIX pax format; i.e.,
+     the lack of a mandatory check sequence in the extended records. *Note
+     crc32::.
 
 '--out-slots=N'
      Number of 1 MiB output packets buffered per worker thread during
      multi-threaded creation or appending to compressed archives.
-     Increasing the number of packets may increase compression speed if
-     the files being archived are larger than 64 MiB compressed, but
-     requires more memory. Valid values range from 1 to 1024. The
-     default value is 64.
+     Increasing the number of packets may increase compression speed if the
+     files being archived are larger than 64 MiB compressed, but requires
+     more memory. Valid values range from 1 to 1024. The default value is
+     64.
 
 
-   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.
+   Exit status: 0 for a normal exit, 1 for environmental problems (file not
+found, files differ, 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.
 
 
 File: tarlz.info,  Node: Portable character set,  Next: File format,  Prev: Invoking tarlz,  Up: Top
@@ -398,8 +414,11 @@ The set of characters from which portable file names are constructed.
      a b c d e f g h i j k l m n o p q r s t u v w x y z
      0 1 2 3 4 5 6 7 8 9 . _ -
 
-   The last three characters are the period, underscore, and
-hyphen-minus characters, respectively.
+   The last three characters are the period, underscore, and hyphen-minus
+characters, respectively.
+
+   File names are identifiers. Therefore, archiving works better when file
+names use only the portable character set without spaces added.
 
 
 File: tarlz.info,  Node: File format,  Next: Amendments to pax format,  Prev: Portable character set,  Up: Top
@@ -408,11 +427,13 @@ File: tarlz.info,  Node: File format,  Next: Amendments to pax format,  Prev: Po
 *************
 
 In the diagram below, a box like this:
+
 +---+
 |   | <-- the vertical bars might be missing
 +---+
 
    represents one byte; a box like this:
+
 +==============+
 |              |
 +==============+
@@ -422,43 +443,43 @@ 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
+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 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:
 
-   * An optional extended header block with extended header records.
-     This header block is of the form described in pax header block,
-     with a typeflag value of 'x'. The extended header records are
-     included as the data for this header block.
+   * An optional extended header block with extended header records. This
+     header block is of the form described in pax header block, with a
+     typeflag value of 'x'. The extended header records are included as the
+     data for this header block.
 
    * A header block in ustar format that describes the file. Any fields
-     defined in the preceding optional extended header records override
-     the associated fields in this header block for this file.
+     defined in the preceding optional extended header records override the
+     associated fields in this header block for this file.
 
    * Zero or more blocks that contain the contents of the file.
 
    Each tar member must be contiguously stored in a lzip member for the
-parallel decoding operations like '--list' to work. If any tar member
-is split over two or more lzip members, the archive must be decoded
-sequentially. *Note Multi-threaded tar::.
+parallel decoding operations like '--list' to work. If any tar member is
+split over two or more lzip members, the archive must be decoded
+sequentially. *Note Multi-threaded decoding::.
 
-   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.
+   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, when
-per file compression is used: *Note File format: (lzip)File format.
+(formed by one or two headers plus optional data) in the tar archive and
+each lzip member in the resulting multimember tar.lz archive, when per file
+compression is used: *Note File format: (lzip)File format.
 
 tar
 +========+======+=================+===============+========+======+========+
@@ -474,62 +495,62 @@ tar.lz
 4.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. Most other
-fields in the pax header block are zeroed on archive creation to
-prevent trouble if the archive is read by an ustar tool, and are
-ignored by tarlz on archive extraction. *Note flawed-compat::.
+The pax header block is identical to the ustar header block described below
+except that the typeflag has the value 'x' (extended). The field 'size' is
+the size of the extended header data in bytes. Most other fields in the pax
+header block are zeroed on archive creation to prevent trouble if the
+archive is read by an ustar tool, and are ignored by tarlz on archive
+extraction. *Note flawed-compat::.
 
    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.
+   The fields <length> and <keyword> in the record must be limited to the
+portable character set (*note Portable character set::). The field <length>
+contains the decimal length of the record in bytes, including the trailing
+newline. The field <value> is stored as-is, without conversion to UTF-8 nor
+any other transformation. The fields are separated by the ASCII characters
+space, equal-sign, and newline.
 
-   These are the <keyword> fields currently supported by tarlz:
+   These are the <keyword> values 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
+     previously archived. This record overrides the field 'linkname' 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.
+     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.
+     The pathname of the following file. This record overrides the fields
+     'name' and 'prefix' 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
+     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 is
-     protected by the CRC 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.
+     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 is protected by the CRC 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.
 
 
 4.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.
+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
@@ -549,34 +570,33 @@ 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 character set.
-But if an implementation supports the use of characters outside of '/'
-and the portable character set in names for files, users, and groups,
-tarlz will use the byte values in these names unmodified.
+   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 character set (*note Portable
+character set::), but if an implementation supports the use of characters
+outside of '/' and the portable 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
+   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 fields 'prefix' and 'name' 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 field 'linkname' 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:
+   The field 'mode' provides 12 access permission bits. The following table
+shows the symbolic name of each bit and its octal value:
 
 Bit Name   Value   Bit Name   Value   Bit Name   Value
 ---------------------------------------------------
@@ -585,30 +605,28 @@ 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
+   The fields 'uid' and 'gid' are the user and group IDs 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
+   The field 'size' contains the octal representation of the size of the
+file in bytes. If the field 'typeflag' 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 field 'mtime' contains the octal representation of the modification
+time of the file at the time it was archived, obtained from the function
+'stat'.
+
+   The field 'chksum' 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 field 'typeflag' contains a single character specifying the type of
 file archived:
 
 ''0''
@@ -621,9 +639,9 @@ file archived:
      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.
+     Character special file and block special file respectively. In this
+     case the fields 'devmajor' and 'devminor' contain information defining
+     the device in unspecified format.
 
 ''5''
      Directory.
@@ -632,157 +650,233 @@ file archived:
      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).
+     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 except when all
+   The field 'magic' contains the ASCII null-terminated string "ustar". The
+field 'version' contains the characters "00" (0x30,0x30). The fields
+'uname' and 'gname' are null-terminated character strings except when all
 characters in the array contain non-null characters including the last
 character. Each numeric field contains a leading space- or zero-filled,
 optionally null-terminated octal number using digits from the ISO/IEC
-646:1991 (ASCII) standard. Tarlz is able to decode numeric fields 1
-byte longer than standard ustar by not requiring a terminating null
-character.
+646:1991 (ASCII) standard. Tarlz is able to decode numeric fields 1 byte
+longer than standard ustar by not requiring a terminating null character.
 
 
-File: tarlz.info,  Node: Amendments to pax format,  Next: Multi-threaded tar,  Prev: File format,  Up: Top
+File: tarlz.info,  Node: Amendments to pax format,  Next: Program design,  Prev: File format,  Up: Top
 
 5 The reasons for the differences with pax
 ******************************************
 
-Tarlz creates safe archives that allow the reliable detection of
-invalid or corrupt metadata during decoding even when the integrity
-checking of lzip can't be used because the lzip members are only
-decompressed partially, as it happens in parallel '--list' and
-'--extract'. In order to achieve this goal, tarlz makes some changes to
-the variant of the pax format that it uses. This chapter describes
-these changes and the concrete reasons to implement them.
+Tarlz creates safe archives that allow the reliable detection of invalid or
+corrupt metadata during decoding even when the integrity checking of lzip
+can't be used because the lzip members are only decompressed partially, as
+it happens in parallel '--diff', '--list', and '--extract'. In order to
+achieve this goal, tarlz makes some changes to the variant of the pax
+format that it uses. This chapter describes these changes and the concrete
+reasons to implement them.
 
 
 5.1 Add a CRC of the extended records
 =====================================
 
-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 file name may cause the extraction of the file in
-the wrong place without warning. Corruption in a large file 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.
+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 file name may cause the extraction of the file in the wrong place
+without warning. Corruption in a large file 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 file name 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.
+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 and archiver misbehavior
+more probable.
 
-   Headers and metadata must be protected separately from data because
-the integrity checking of lzip may not be able to detect the corruption
-before the metadata has been used, for example, to create a new file in
-the wrong place.
+   Headers and metadata must be protected separately from data because the
+integrity checking of lzip may not be able to detect the corruption before
+the metadata has been used, for example, to create a new file in the wrong
+place.
 
-   Because of the above, tarlz protects the extended records with a CRC
-in a way compatible with standard tar tools. *Note key_crc32::.
+   Because of the above, tarlz protects the extended records with a CRC in a
+way compatible with standard tar tools. *Note key_crc32::.
 
 
 5.2 Remove flawed backward compatibility
 ========================================
 
-In order to allow the extraction of pax archives by a tar utility
-conforming to the POSIX-2:1993 standard, POSIX.1-2008 recommends
-selecting extended header field values that allow such tar to create a
-regular file containing the extended header records as data. This
-approach is broken because if the extended header is needed because of
-a long file name, the name and prefix fields will be unable to contain
-the full pathname of the file. Therefore the files corresponding to
-both the extended header and the overridden ustar header will be
-extracted using truncated file names, perhaps overwriting existing
-files or directories. It may be a security risk to extract a file with
-a truncated file name.
+In order to allow the extraction of pax archives by a tar utility conforming
+to the POSIX-2:1993 standard, POSIX.1-2008 recommends selecting extended
+header field values that allow such tar to create a regular file containing
+the extended header records as data. This approach is broken because if the
+extended header is needed because of a long file name, the fields 'prefix'
+and 'name' will be unable to contain the full pathname of the file.
+Therefore the files corresponding to both the extended header and the
+overridden ustar header will be extracted using truncated file names,
+perhaps overwriting existing files or directories. It may be a security risk
+to extract a file with a truncated file name.
 
    To avoid this problem, tarlz writes extended headers with all fields
-zeroed except size, chksum, typeflag, magic and version. This prevents
-old tar programs from extracting the extended records as a file in the
-wrong place.  Tarlz also sets to zero those fields of the ustar header
-overridden by extended records.
+zeroed except size, chksum, typeflag, magic and version. This prevents old
+tar programs from extracting the extended records as a file in the wrong
+place. Tarlz also sets to zero those fields of the ustar header overridden
+by extended records.
 
-   If an extended header is required for any reason (for example a file
-size larger than 8 GiB or a link name longer than 100 bytes), tarlz
-moves the file name also to the extended header to prevent an ustar
-tool from trying to extract the file or link. This also makes easier
-during parallel decoding the detection of a tar member split between
-two lzip members at the boundary between the extended header and the
-ustar header.
+   If an extended header is required for any reason (for example a file size
+larger than 8 GiB or a link name longer than 100 bytes), tarlz moves the
+file name also to the extended header to prevent an ustar tool from trying
+to extract the file or link. This also makes easier during parallel decoding
+the detection of a tar member split between two lzip members at the boundary
+between the extended header and the ustar header.
 
 
 5.3 As simple as possible (but not simpler)
 ===========================================
 
-The tarlz format is mainly ustar. Extended pax headers are used only
-when needed because the length of a file name or link name, or the size
-of a file exceed the limits of the ustar format. Adding extended
-headers to each member just to record subsecond timestamps seems
-wasteful for a backup format. Moreover, minimizing the overhead may
-help recovering the archive with lziprecover in case of corruption.
+The tarlz format is mainly ustar. Extended pax headers are used only when
+needed because the length of a file name or link name, or the size of a file
+exceed the limits of the ustar format. Adding 1 KiB of extended headers to
+each member just to record subsecond timestamps seems wasteful for a backup
+format. Moreover, minimizing the overhead may help recovering the archive
+with lziprecover in case of corruption.
 
-   Global pax headers are tolerated, but not supported; they are parsed
-and ignored. Some operations may not behave as expected if the archive
-contains global headers.
+   Global pax headers are tolerated, but not supported; they are parsed and
+ignored. Some operations may not behave as expected if the archive contains
+global headers.
 
 
 5.4 Avoid misconversions to/from UTF-8
 ======================================
 
-There is no portable way to tell what charset a text string is coded
-into.  Therefore, tarlz stores all fields representing text strings
-unmodified, without conversion to UTF-8 nor any other transformation.
-This prevents accidental double UTF-8 conversions. If the need arises
-this behavior will be adjusted with a command line option in the future.
+There is no portable way to tell what charset a text string is coded into.
+Therefore, tarlz stores all fields representing text strings unmodified,
+without conversion to UTF-8 nor any other transformation. This prevents
+accidental double UTF-8 conversions. If the need arises this behavior will
+be adjusted with a command line option in the future.
 
 
-File: tarlz.info,  Node: Multi-threaded tar,  Next: Minimum archive sizes,  Prev: Amendments to pax format,  Up: Top
+File: tarlz.info,  Node: Program design,  Next: Multi-threaded decoding,  Prev: Amendments to pax format,  Up: Top
+
+6 Internal structure of tarlz
+*****************************
+
+The parts of tarlz related to sequential processing of the archive are more
+or less similar to any other tar and won't be described here. The
+interesting parts described here are those related to Multi-threaded
+processing.
+
+   The structure of the part of tarlz performing Multi-threaded archive
+creation is somewhat similar to that of plzip with the added complication of
+the solidity levels. A grouper thread and several worker threads are
+created, acting the main thread as muxer (multiplexer) thread. A "packet
+courier" takes care of data transfers among threads and limits the maximum
+number of data blocks (packets) being processed simultaneously.
+
+   The grouper traverses the directory tree, groups together the metadata of
+the files to be archived in each lzip member, and distributes them to the
+workers. The workers compress the metadata received from the grouper along
+with the file data read from the file system. The muxer collects processed
+packets from the workers, and writes them to the archive.
+
+,--------,
+|    data|---> to each worker below
+|        |                    ,------------,
+| file   |                ,-->| worker   0 |--,
+| system |                |   `------------'  |
+|        |    ,---------, |   ,------------,  |   ,-------,   ,---------,
+|metadata|--->| grouper |-+-->| worker   1 |--+-->| muxer |-->| archive |
+`--------'    `---------' |   `------------'  |   `-------'   `---------'
+                          |        ...        |
+                          |   ,------------,  |
+                          `-->| worker N-1 |--'
+                              `------------'
+
+   Decoding an archive is somewhat similar to how plzip decompresses a
+regular file to standard output, with the differences that it is not the
+data but only messages what is written to stdout/stderr, and that each
+worker may access files in the file system either to read them (diff) or
+write them (extract). As in plzip, each worker reads members directly from
+the archive.
+
+,--------,
+| file   |<---> data to/from each worker below
+| system |
+`--------'
+                ,------------,
+            ,-->| worker   0 |--,
+            |   `------------'  |
+,---------, |   ,------------,  |   ,-------,   ,--------,
+| archive |-+-->| worker   1 |--+-->| muxer |-->| stdout |
+`---------' |   `------------'  |   `-------'   | stderr |
+            |        ...        |               `--------'
+            |   ,------------,  |
+            `-->| worker N-1 |--'
+                `------------'
+
+   As misaligned tar.lz archives can't be decoded in parallel, and the
+misalignment can't be detected until after decoding has started, a
+"mastership request" mechanism has been designed that allows the decoding to
+continue instead of signalling an error.
+
+   During parallel decoding, if a worker finds a misalignment, it requests
+mastership to decode the rest of the archive. When mastership is requested,
+an error_member_id is set, and all subsequently received packets with
+member_id > error_member_id are rejected. All workers requesting mastership
+are blocked at the request_mastership call until mastership is granted.
+Mastership is granted to the delivering worker when its queue is empty to
+make sure that all preceding packets have been processed. When mastership is
+granted, all packets are deleted and all subsequently received packets not
+coming from the master are rejected.
+
+   If a worker can't continue decoding for any cause (for example lack of
+memory or finding a split tar member at the beginning of a lzip member), it
+requests mastership to print an error and terminate the program. Only if
+some other worker requests mastership in a previous lzip member can this
+error be avoided.
 
-6 Limitations of parallel tar decoding
+
+File: tarlz.info,  Node: Multi-threaded decoding,  Next: Minimum archive sizes,  Prev: Program design,  Up: Top
+
+7 Limitations of parallel tar decoding
 **************************************
 
 Safely decoding an arbitrary tar archive in parallel is impossible. For
-example, if a tar archive containing another tar archive is decoded
-starting from some position other than the beginning, there is no way
-to know if the first header found there belongs to the outer tar
-archive or to the inner tar archive. Tar is a format inherently serial;
-it was designed for tapes.
+example, if a tar archive containing another tar archive is decoded starting
+from some position other than the beginning, there is no way to know if the
+first header found there belongs to the outer tar archive or to the inner
+tar archive. Tar is a format inherently serial; it was designed for tapes.
 
    In the case of compressed tar archives, the start of each compressed
-block determines one point through which the tar archive can be decoded
-in parallel. Therefore, in tar.lz archives the decoding operations
-can't be parallelized if the tar members are not aligned with the lzip
-members. Tar archives compressed with plzip can't be decoded in
-parallel because tar and plzip do not have a way to align both sets of
-members. Certainly one can decompress one such archive with a
-multi-threaded tool like plzip, but the increase in speed is not as
-large as it could be because plzip must serialize the decompressed data
-and pass them to tar, which decodes them sequentially, one tar member
-at a time.
+block determines one point through which the tar archive can be decoded in
+parallel. Therefore, in tar.lz archives the decoding operations can't be
+parallelized if the tar members are not aligned with the lzip members. Tar
+archives compressed with plzip can't be decoded in parallel because tar and
+plzip do not have a way to align both sets of members. Certainly one can
+decompress one such archive with a multi-threaded tool like plzip, but the
+increase in speed is not as large as it could be because plzip must
+serialize the decompressed data and pass them to tar, which decodes them
+sequentially, one tar member at a time.
 
    On the other hand, if the tar.lz archive is created with a tool like
 tarlz, which can guarantee the alignment between tar members and lzip
-members because it controls both archiving and compression, then the
-lzip format becomes an indexed layer on top of the tar archive which
-makes possible decoding it safely in parallel.
+members because it controls both archiving and compression, then the lzip
+format becomes an indexed layer on top of the tar archive which makes
+possible decoding it safely in parallel.
 
-   Tarlz is able to automatically decode aligned and unaligned
-multimember tar.lz archives, keeping backwards compatibility. If tarlz
-finds a member misalignment during multi-threaded decoding, it switches
-to single-threaded mode and continues decoding the archive. Currently
-only the '--list' option is able to do multi-threaded decoding.
+   Tarlz is able to automatically decode aligned and unaligned multimember
+tar.lz archives, keeping backwards compatibility. If tarlz finds a member
+misalignment during multi-threaded decoding, it switches to single-threaded
+mode and continues decoding the archive. Currently only the options
+'--diff' and '--list' are able to do multi-threaded decoding.
 
    If the files in the archive are large, multi-threaded '--list' on a
 regular (seekable) tar.lz archive can be hundreds of times faster than
-sequential '--list' because, in addition to using several processors,
-it only needs to decompress part of each lzip member. See the following
+sequential '--list' because, in addition to using several processors, it
+only needs to decompress part of each lzip member. See the following
 example listing the Silesia corpus on a dual core machine:
 
      tarlz -9 --no-solid -cf silesia.tar.lz silesia
@@ -790,29 +884,33 @@ example listing the Silesia corpus on a dual core machine:
      time plzip -cd silesia.tar.lz | tar -tf -           (3.256s)
      time tarlz -tf silesia.tar.lz                       (0.020s)
 
+   On the other hand, multi-threaded '--list' won't detect corruption in
+the tar member data because it only decodes the part of each lzip member
+corresponding to the tar member header.
+
 
-File: tarlz.info,  Node: Minimum archive sizes,  Next: Examples,  Prev: Multi-threaded tar,  Up: Top
+File: tarlz.info,  Node: Minimum archive sizes,  Next: Examples,  Prev: Multi-threaded decoding,  Up: Top
 
-7 Minimum archive sizes required for multi-threaded block compression
+8 Minimum archive sizes required for multi-threaded block compression
 *********************************************************************
 
 When creating or appending to a compressed archive using multi-threaded
-block compression, tarlz puts tar members together in blocks and
-compresses as many blocks simultaneously as worker threads are chosen,
-creating a multimember compressed archive.
-
-   For this to work as expected (and roughly multiply the compression
-speed by the number of available processors), the uncompressed archive
-must be at least as large as the number of worker threads times the
-block size (*note --data-size::). Else some processors will not get any
-data to compress, and compression will be proportionally slower. The
-maximum speed increase achievable on a given archive is limited by the
-ratio (uncompressed_size / data_size). For example, a tarball the size
-of gcc or linux will scale up to 10 or 12 processors at level -9.
-
-   The following table shows the minimum uncompressed archive size
-needed for full use of N processors at a given compression level, using
-the default data size for each level:
+block compression, tarlz puts tar members together in blocks and compresses
+as many blocks simultaneously as worker threads are chosen, creating a
+multimember compressed archive.
+
+   For this to work as expected (and roughly multiply the compression speed
+by the number of available processors), the uncompressed archive must be at
+least as large as the number of worker threads times the block size (*note
+--data-size::). Else some processors will not get any data to compress, and
+compression will be proportionally slower. The maximum speed increase
+achievable on a given archive is limited by the ratio
+(uncompressed_size / data_size). For example, a tarball the size of gcc or
+linux will scale up to 10 or 14 processors at level -9.
+
+   The following table shows the minimum uncompressed archive size needed
+for full use of N processors at a given compression level, using the default
+data size for each level:
 
 Processors   2         4         8         16        64        256
 ------------------------------------------------------------------
@@ -831,7 +929,7 @@ Level
 
 File: tarlz.info,  Node: Examples,  Next: Problems,  Prev: Minimum archive sizes,  Up: Top
 
-8 A small tutorial with examples
+9 A small tutorial with examples
 ********************************
 
 Example 1: Create a multimember compressed archive 'archive.tar.lz'
@@ -840,33 +938,33 @@ 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'.
+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.
+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).
+'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.
+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.
 
      tarlz --solid -cf archive.tar.lz a b c
 
@@ -876,8 +974,8 @@ Example 6: Extract all files from archive 'archive.tar.lz'.
      tarlz -xf archive.tar.lz
 
 
-Example 7: Extract files 'a' and 'c', and the whole tree under
-directory 'dir1' from archive 'archive.tar.lz'.
+Example 7: Extract files 'a' and 'c', and the whole tree under directory
+'dir1' from archive 'archive.tar.lz'.
 
      tarlz -xf archive.tar.lz a c dir1
 
@@ -890,17 +988,17 @@ Example 8: Copy the contents of directory 'sourcedir' to the directory
 
 File: tarlz.info,  Node: Problems,  Next: Concept index,  Prev: Examples,  Up: Top
 
-9 Reporting bugs
-****************
+10 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.
+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'.
+<lzip-bug@nongnu.org>. Include the version number, which you can find by
+running 'tarlz --version'.
 
 
 File: tarlz.info,  Node: Concept index,  Prev: Problems,  Up: Top
@@ -911,41 +1009,41 @@ Concept index
 
 * Menu:
 
-* Amendments to pax format:              Amendments to pax format.
-                                                                (line 6)
-* bugs:                                  Problems.              (line 6)
-* examples:                              Examples.              (line 6)
-* file format:                           File format.           (line 6)
-* getting help:                          Problems.              (line 6)
-* introduction:                          Introduction.          (line 6)
-* invoking:                              Invoking tarlz.        (line 6)
-* minimum archive sizes:                 Minimum archive sizes. (line 6)
-* options:                               Invoking tarlz.        (line 6)
-* parallel tar decoding:                 Multi-threaded tar.    (line 6)
-* portable character set:                Portable character set.
-                                                                (line 6)
-* usage:                                 Invoking tarlz.        (line 6)
-* version:                               Invoking tarlz.        (line 6)
+* Amendments to pax format:              Amendments to pax format.  (line 6)
+* bugs:                                  Problems.                  (line 6)
+* examples:                              Examples.                  (line 6)
+* file format:                           File format.               (line 6)
+* getting help:                          Problems.                  (line 6)
+* introduction:                          Introduction.              (line 6)
+* invoking:                              Invoking tarlz.            (line 6)
+* minimum archive sizes:                 Minimum archive sizes.     (line 6)
+* options:                               Invoking tarlz.            (line 6)
+* parallel tar decoding:                 Multi-threaded decoding.   (line 6)
+* portable character set:                Portable character set.    (line 6)
+* program design:                        Program design.            (line 6)
+* usage:                                 Invoking tarlz.            (line 6)
+* version:                               Invoking tarlz.            (line 6)
 
 
 
 Tag Table:
 Node: Top223
-Node: Introduction1155
-Node: Invoking tarlz3841
-Ref: --data-size6006
-Ref: --bsolid13287
-Node: Portable character set16917
-Node: File format17420
-Ref: key_crc3222248
-Node: Amendments to pax format27647
-Ref: crc3228304
-Ref: flawed-compat29564
-Node: Multi-threaded tar32198
-Node: Minimum archive sizes34737
-Node: Examples36870
-Node: Problems38587
-Node: Concept index39113
+Node: Introduction1212
+Node: Invoking tarlz3982
+Ref: --data-size6193
+Ref: --bsolid14608
+Node: Portable character set18244
+Node: File format18887
+Ref: key_crc3223812
+Node: Amendments to pax format29271
+Ref: crc3229935
+Ref: flawed-compat31220
+Node: Program design33865
+Node: Multi-threaded decoding37756
+Node: Minimum archive sizes40492
+Node: Examples42630
+Node: Problems44345
+Node: Concept index44873
 
 End Tag Table
 
diff --git a/doc/tarlz.texi b/doc/tarlz.texi
index 25acaf8..00116ee 100644
--- a/doc/tarlz.texi
+++ b/doc/tarlz.texi
@@ -6,8 +6,8 @@
 @finalout
 @c %**end of header
 
-@set UPDATED 8 October 2019
-@set VERSION 0.16
+@set UPDATED 30 July 2020
+@set VERSION 0.17
 
 @dircategory Data Compression
 @direntry
@@ -40,7 +40,8 @@ This manual is for Tarlz (version @value{VERSION}, @value{UPDATED}).
 * Portable character set::    POSIX portable filename character set
 * File format::               Detailed format of the compressed archive
 * Amendments to pax format::  The reasons for the differences with pax
-* Multi-threaded tar::        Limitations of parallel tar decoding
+* Program design::            Internal structure of tarlz
+* Multi-threaded decoding::   Limitations of parallel tar decoding
 * Minimum archive sizes::     Sizes required for full multi-threaded speed
 * Examples::                  A small tutorial with examples
 * Problems::                  Reporting bugs
@@ -48,10 +49,10 @@ This manual is for Tarlz (version @value{VERSION}, @value{UPDATED}).
 @end menu
 
 @sp 1
-Copyright @copyright{} 2013-2019 Antonio Diaz Diaz.
+Copyright @copyright{} 2013-2020 Antonio Diaz Diaz.
 
 This manual is free documentation: you have unlimited permission
-to copy, distribute and modify it.
+to copy, distribute, and modify it.
 
 
 @node Introduction
@@ -77,7 +78,8 @@ because it does not keep the members aligned.
 
 Tarlz can create tar archives with five levels of compression granularity;
 per file (---no-solid), per block (---bsolid, default), per directory
-(---dsolid), appendable solid (---asolid), and solid (---solid).
+(---dsolid), appendable solid (---asolid), and solid (---solid). It can also
+create uncompressed tar archives.
 
 @noindent
 Of course, compressing each file (or each directory) individually can't
@@ -105,16 +107,16 @@ and lziprecover can be used to recover some of the damaged members.
 @item
 A multimember tar.lz archive is usually smaller than the
 corresponding solidly compressed tar.gz archive, except when
-individually compressing files smaller than about 32 KiB.
+compressing files smaller than about 32 KiB individually.
 @end itemize
 
-Tarlz protects the extended records with a CRC in a way compatible with
-standard tar tools. @xref{crc32}.
+Tarlz protects the extended records with a Cyclic Redundancy Check (CRC) in
+a way compatible with standard tar tools. @xref{crc32}.
 
 Tarlz does not understand other tar formats like @samp{gnu}, @samp{oldgnu},
-@samp{star} or @samp{v7}. @w{@samp{tarlz -tf archive.tar.lz > /dev/null}}
-can be used to verify that the format of the archive is compatible with
-tarlz.
+@samp{star} or @samp{v7}. The command
+@w{@samp{tarlz -tf archive.tar.lz > /dev/null}} can be used to verify that
+the format of the archive is compatible with tarlz.
 
 
 @node Invoking tarlz
@@ -151,7 +153,11 @@ If several compression levels or @samp{--*solid} options are given, the last
 setting is used. For example @w{@samp{-9 --solid --uncompressed -1}} is
 equivalent to @samp{-1 --solid}
 
-tarlz supports the following options:
+tarlz supports the following
+@uref{http://www.nongnu.org/arg-parser/manual/arg_parser_manual.html#Argument-syntax,,options}:
+@ifnothtml
+@xref{Argument syntax,,,arg_parser}.
+@end ifnothtml
 
 @table @code
 @item --help
@@ -177,7 +183,7 @@ modifying the archive if no @var{files} have been specified.
 @anchor{--data-size}
 @item -B @var{bytes}
 @itemx --data-size=@var{bytes}
-Set target size of input data blocks for the @samp{--bsolid} option.
+Set target size of input data blocks for the option @samp{--bsolid}.
 @xref{--bsolid}. Valid values range from @w{8 KiB} to @w{1 GiB}. Default
 value is two times the dictionary size, except for option @samp{-0} where it
 defaults to @w{1 MiB}. @xref{Minimum archive sizes}.
@@ -210,7 +216,7 @@ standard output the differences found in type, mode (permissions), owner and
 group IDs, modification time, file size, file contents (of regular files),
 target (of symlinks) and device number (of block/character special files).
 
-As tarlz removes leading slashes from member names, the @samp{-C} option may
+As tarlz removes leading slashes from member names, the option @samp{-C} may
 be used in combination with @samp{--diff} when absolute file names were used
 on archive creation: @w{@samp{tarlz -C / -d}}. Alternatively, tarlz may be
 run from the root directory to perform the comparison.
@@ -220,14 +226,18 @@ Make @samp{--diff} ignore differences in owner and group IDs. This option is
 useful when comparing an @samp{--anonymous} archive.
 
 @item --delete
-Delete the specified files and directories from an archive in place. It
-currently can delete only from uncompressed archives and from archives with
-individually compressed files (@samp{--no-solid} archives). Note that files
-of about @samp{--data-size} or larger are compressed individually even if
+Delete files and directories from an archive in place. It currently can
+delete only from uncompressed archives and from archives with files
+compressed individually (@samp{--no-solid} archives). Note that files of
+about @samp{--data-size} or larger are compressed individually even if
 @samp{--bsolid} is used, and can therefore be deleted. Tarlz takes care to
 not delete a tar member unless it is possible to do so. For example it won't
-try to delete a tar member that is not individually compressed. To delete a
-directory without deleting the files under it, use
+try to delete a tar member that is not compressed individually. Even in the
+case of finding a corrupt member after having deleted some member(s), tarlz
+stops and copies the rest of the file as soon as corruption is found,
+leaving it just as corrupt as it was, but not worse.
+
+To delete a directory without deleting the files under it, use
 @w{@samp{tarlz --delete -f foo --exclude='dir/*' dir}}. Deleting in place
 may be dangerous. A corrupt archive, a power cut, or an I/O error may cause
 data loss.
@@ -241,14 +251,22 @@ the file name. For example, @samp{foo/*.o} matches @samp{foo/bar.o}.
 
 @item -f @var{archive}
 @itemx --file=@var{archive}
-Use archive file @var{archive}. @samp{-} used as an @var{archive} argument
-reads from standard input or writes to standard output.
+Use archive file @var{archive}. A hyphen @samp{-} used as an @var{archive}
+argument reads from standard input or writes to standard output.
 
 @item -h
 @itemx --dereference
 Follow symbolic links during archive creation, appending or comparison.
 Archive or compare the files they point to instead of the links themselves.
 
+@item --mtime=@var{date}
+When creating or appending, use @var{date} as the modification time for
+files added to the archive instead of their actual modification times. The
+value of @var{date} may be either @samp{@@} followed by the number of
+seconds since the epoch, or a date in format @w{@samp{YYYY-MM-DD HH:MM:SS}},
+or the name of an existing file starting with @samp{.} or @samp{/}. In the
+latter case, the modification time of that file is used.
+
 @item -n @var{n}
 @itemx --threads=@var{n}
 Set the number of (de)compression threads, overriding the system's default.
@@ -256,15 +274,22 @@ Valid values range from 0 to "as many as your system can support". A value
 of 0 disables threads entirely. If this option is not used, tarlz tries to
 detect the number of processors in the system and use it as default value.
 @w{@samp{tarlz --help}} shows the system's default value. See the note about
-multi-threaded archive creation in the @samp{-C} option above.
+multi-threaded archive creation in the option @samp{-C} above.
 Multi-threaded extraction of files from an archive is not yet implemented.
-@xref{Multi-threaded tar}.
+@xref{Multi-threaded decoding}.
 
 Note that the number of usable threads is limited during compression to
 @w{ceil( uncompressed_size / data_size )} (@pxref{Minimum archive sizes}),
 and during decompression to the number of lzip members in the tar.lz
 archive, which you can find by running @w{@samp{lzip -lv archive.tar.lz}}.
 
+@item -p
+@itemx --preserve-permissions
+On extraction, set file permissions as they appear in the archive. This is
+the default behavior when tarlz is run by the superuser. The default for
+other users is to subtract the umask of the user running tarlz from the
+permissions specified in the archive.
+
 @item -q
 @itemx --quiet
 Quiet operation. Suppress all messages.
@@ -298,7 +323,10 @@ Verbosely list files processed.
 Extract files from an archive. If @var{files} are given, extract only the
 @var{files} given. Else extract all the files in the archive. To extract a
 directory without extracting the files under it, use
-@w{@samp{tarlz -xf foo --exclude='dir/*' dir}}.
+@w{@samp{tarlz -xf foo --exclude='dir/*' dir}}. Tarlz will not make any
+special effort to extract a file over an incompatible type of file. For
+example, extracting a link over a directory will usually fail. (Principle of
+least surprise).
 
 @item -0 .. -9
 Set the compression level for @samp{--create} and @samp{--append}. The
@@ -411,9 +439,9 @@ keyword appearing in the same block of extended records.
 @end table
 
 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.
+found, files differ, 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.
 
 
 @node Portable character set
@@ -431,12 +459,16 @@ a b c d e f g h i j k l m n o p q r s t u v w x y z
 The last three characters are the period, underscore, and hyphen-minus
 characters, respectively.
 
+File names are identifiers. Therefore, archiving works better when file
+names use only the portable character set without spaces added.
+
 
 @node File format
 @chapter File format
 @cindex file format
 
 In the diagram below, a box like this:
+
 @verbatim
 +---+
 |   | <-- the vertical bars might be missing
@@ -444,6 +476,7 @@ In the diagram below, a box like this:
 @end verbatim
 
 represents one byte; a box like this:
+
 @verbatim
 +==============+
 |              |
@@ -486,7 +519,7 @@ Zero or more blocks that contain the contents of the file.
 Each tar member must be contiguously stored in a lzip member for the
 parallel decoding operations like @samp{--list} to work. If any tar member
 is split over two or more lzip members, the archive must be decoded
-sequentially. @xref{Multi-threaded tar}.
+sequentially. @xref{Multi-threaded decoding}.
 
 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
@@ -530,28 +563,29 @@ An extended header just before the EOF blocks.
 @section Pax header block
 
 The pax header block is identical to the ustar header block described below
-except that the typeflag has the value @samp{x} (extended). The size field
-is the size of the extended header data in bytes. Most other fields in the
-pax header block are zeroed on archive creation to prevent trouble if the
-archive is read by an ustar tool, and are ignored by tarlz on archive
-extraction. @xref{flawed-compat}.
+except that the typeflag has the value @samp{x} (extended). The field
+@samp{size} is the size of the extended header data in bytes. Most other
+fields in the pax header block are zeroed on archive creation to prevent
+trouble if the archive is read by an ustar tool, and are ignored by tarlz on
+archive extraction. @xref{flawed-compat}.
 
 The pax extended header data consists of one or more records, each of
 them constructed as follows:@*
 @samp{"%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.
+The fields <length> and <keyword> in the record must be limited to the
+portable character set (@pxref{Portable character set}). The field <length>
+contains the decimal length of the record in bytes, including the trailing
+newline. The field <value> is stored as-is, without conversion to UTF-8 nor
+any other transformation. The fields are separated by the ASCII characters
+space, equal-sign, and newline.
 
-These are the <keyword> fields currently supported by tarlz:
+These are the <keyword> values currently supported by tarlz:
 
 @table @code
 @item linkpath
 The pathname of a link being created to another file, of any type,
-previously archived. This record overrides the linkname field in the
+previously archived. This record overrides the field @samp{linkname} 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
@@ -559,8 +593,8 @@ symbolic link and the linkpath value will be used as the contents of the
 symbolic link.
 
 @item path
-The pathname of the following file. This record overrides the name and
-prefix fields in the following ustar header block.
+The pathname of the following file. This record overrides the fields
+@samp{name} and @samp{prefix} in the following ustar header block.
 
 @item size
 The size of the file in bytes, expressed as a decimal number using
@@ -610,31 +644,30 @@ shown in the following table. All lengths and offsets are in decimal.
 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 character set. But if an implementation
-supports the use of characters outside of @samp{/} and the portable
-character set in names for files, users, and groups, tarlz will use the byte
-values in these names unmodified.
+contain characters from the portable character set (@pxref{Portable
+character set}), but if an implementation supports the use of characters
+outside of @samp{/} and the portable 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 fields @samp{name}, @samp{linkname}, and @samp{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
+The fields @samp{prefix} and @samp{name} 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
+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 field @samp{linkname} 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:
+The field @samp{mode} provides 12 access permission bits. The following
+table shows the symbolic name of each bit and its octal value:
 
 @multitable {Bit Name} {Value} {Bit Name} {Value} {Bit Name} {Value}
 @headitem Bit Name @tab Value @tab Bit Name @tab Value @tab Bit Name @tab Value
@@ -644,29 +677,28 @@ shows the symbolic name of each bit and its octal value:
 @item S_IROTH @tab 00004 @tab S_IWOTH @tab 00002 @tab S_IXOTH @tab 00001
 @end multitable
 
-The uid and gid fields are the user and group ID of the owner and group
-of the file, respectively.
+The fields @samp{uid} and @samp{gid} are the user and group IDs 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
+The field @samp{size} contains the octal representation of the size of the
+file in bytes. If the field @samp{typeflag} specifies a file of type '0'
+(regular file) or '7' (high performance regular file), the number of logical
 records following the header is @w{(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 @w{(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
+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
+@w{(octal 77777777777)}, an extended record is used to store the file size.
+
+The field @samp{mtime} contains the octal representation of the modification
+time of the file at the time it was archived, obtained from the function
+@samp{stat}.
+
+The field @samp{chksum} 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 field @samp{typeflag} contains a single character specifying the type of
 file archived:
 
 @table @code
@@ -680,8 +712,8 @@ Hard link to another file, of any type, previously archived.
 Symbolic link.
 
 @item '3', '4'
-Character special file and block special file respectively. In this case
-the devmajor and devminor fields contain information defining the
+Character special file and block special file respectively. In this case the
+fields @samp{devmajor} and @samp{devminor} contain information defining the
 device in unspecified format.
 
 @item '5'
@@ -697,14 +729,15 @@ regular file (type 0).
 
 @end table
 
-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 except when all characters
-in the array contain non-null characters including the last character. Each
-numeric field contains a leading space- or zero-filled, optionally
-null-terminated octal number using digits from the ISO/IEC 646:1991 (ASCII)
-standard. Tarlz is able to decode numeric fields 1 byte longer than standard
-ustar by not requiring a terminating null character.
+The field @samp{magic} contains the ASCII null-terminated string "ustar".
+The field @samp{version} contains the characters "00" (0x30,0x30). The
+fields @samp{uname} and @samp{gname} are null-terminated character strings
+except when all characters in the array contain non-null characters
+including the last character. Each numeric field contains a leading space-
+or zero-filled, optionally null-terminated octal number using digits from
+the ISO/IEC 646:1991 (ASCII) standard. Tarlz is able to decode numeric
+fields 1 byte longer than standard ustar by not requiring a terminating null
+character.
 
 
 @node Amendments to pax format
@@ -714,10 +747,10 @@ ustar by not requiring a terminating null character.
 Tarlz creates safe archives that allow the reliable detection of invalid or
 corrupt metadata during decoding even when the integrity checking of lzip
 can't be used because the lzip members are only decompressed partially, as
-it happens in parallel @samp{--list} and @samp{--extract}. In order to
-achieve this goal, tarlz makes some changes to the variant of the pax format
-that it uses. This chapter describes these changes and the concrete reasons
-to implement them.
+it happens in parallel @samp{--diff}, @samp{--list}, and @samp{--extract}.
+In order to achieve this goal, tarlz makes some changes to the variant of
+the pax format that it uses. This chapter describes these changes and the
+concrete reasons to implement them.
 
 @sp 1
 @anchor{crc32}
@@ -735,7 +768,7 @@ Metadata like file name 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.
+large, making undetected corruption and archiver misbehavior more probable.
 
 Headers and metadata must be protected separately from data because the
 integrity checking of lzip may not be able to detect the corruption before
@@ -753,12 +786,12 @@ In order to allow the extraction of pax archives by a tar utility conforming
 to the POSIX-2:1993 standard, POSIX.1-2008 recommends selecting extended
 header field values that allow such tar to create a regular file containing
 the extended header records as data. This approach is broken because if the
-extended header is needed because of a long file name, the name and prefix
-fields will be unable to contain the full pathname of the file. Therefore
-the files corresponding to both the extended header and the overridden ustar
-header will be extracted using truncated file names, perhaps overwriting
-existing files or directories. It may be a security risk to extract a file
-with a truncated file name.
+extended header is needed because of a long file name, the fields
+@samp{prefix} and @samp{name} will be unable to contain the full pathname of
+the file. Therefore the files corresponding to both the extended header and
+the overridden ustar header will be extracted using truncated file names,
+perhaps overwriting existing files or directories. It may be a security risk
+to extract a file with a truncated file name.
 
 To avoid this problem, tarlz writes extended headers with all fields zeroed
 except size, chksum, typeflag, magic and version. This prevents old tar
@@ -778,10 +811,10 @@ between the extended header and the ustar header.
 
 The tarlz format is mainly ustar. Extended pax headers are used only when
 needed because the length of a file name or link name, or the size of a file
-exceed the limits of the ustar format. Adding extended headers to each
-member just to record subsecond timestamps seems wasteful for a backup
-format. Moreover, minimizing the overhead may help recovering the archive
-with lziprecover in case of corruption.
+exceed the limits of the ustar format. Adding @w{1 KiB} of extended headers
+to each member just to record subsecond timestamps seems wasteful for a
+backup format. Moreover, minimizing the overhead may help recovering the
+archive with lziprecover in case of corruption.
 
 Global pax headers are tolerated, but not supported; they are parsed and
 ignored. Some operations may not behave as expected if the archive contains
@@ -797,7 +830,88 @@ accidental double UTF-8 conversions. If the need arises this behavior will
 be adjusted with a command line option in the future.
 
 
-@node Multi-threaded tar
+@node Program design
+@chapter Internal structure of tarlz
+@cindex program design
+
+The parts of tarlz related to sequential processing of the archive are more
+or less similar to any other tar and won't be described here. The interesting
+parts described here are those related to Multi-threaded processing.
+
+The structure of the part of tarlz performing Multi-threaded archive
+creation is somewhat similar to that of plzip with the added complication of
+the solidity levels. A grouper thread and several worker threads are
+created, acting the main thread as muxer (multiplexer) thread. A "packet
+courier" takes care of data transfers among threads and limits the maximum
+number of data blocks (packets) being processed simultaneously.
+
+The grouper traverses the directory tree, groups together the metadata of
+the files to be archived in each lzip member, and distributes them to the
+workers. The workers compress the metadata received from the grouper along
+with the file data read from the file system. The muxer collects processed
+packets from the workers, and writes them to the archive.
+
+@verbatim
+,--------,
+|    data|---> to each worker below
+|        |                    ,------------,
+| file   |                ,-->| worker   0 |--,
+| system |                |   `------------'  |
+|        |    ,---------, |   ,------------,  |   ,-------,   ,---------,
+|metadata|--->| grouper |-+-->| worker   1 |--+-->| muxer |-->| archive |
+`--------'    `---------' |   `------------'  |   `-------'   `---------'
+                          |        ...        |
+                          |   ,------------,  |
+                          `-->| worker N-1 |--'
+                              `------------'
+@end verbatim
+
+Decoding an archive is somewhat similar to how plzip decompresses a regular
+file to standard output, with the differences that it is not the data but
+only messages what is written to stdout/stderr, and that each worker may
+access files in the file system either to read them (diff) or write them
+(extract). As in plzip, each worker reads members directly from the archive.
+
+@verbatim
+,--------,
+| file   |<---> data to/from each worker below
+| system |
+`--------'
+                ,------------,
+            ,-->| worker   0 |--,
+            |   `------------'  |
+,---------, |   ,------------,  |   ,-------,   ,--------,
+| archive |-+-->| worker   1 |--+-->| muxer |-->| stdout |
+`---------' |   `------------'  |   `-------'   | stderr |
+            |        ...        |               `--------'
+            |   ,------------,  |
+            `-->| worker N-1 |--'
+                `------------'
+@end verbatim
+
+As misaligned tar.lz archives can't be decoded in parallel, and the
+misalignment can't be detected until after decoding has started, a
+"mastership request" mechanism has been designed that allows the decoding to
+continue instead of signalling an error.
+
+During parallel decoding, if a worker finds a misalignment, it requests
+mastership to decode the rest of the archive. When mastership is requested,
+an error_member_id is set, and all subsequently received packets with
+member_id > error_member_id are rejected. All workers requesting mastership
+are blocked at the request_mastership call until mastership is granted.
+Mastership is granted to the delivering worker when its queue is empty to
+make sure that all preceding packets have been processed. When mastership is
+granted, all packets are deleted and all subsequently received packets not
+coming from the master are rejected.
+
+If a worker can't continue decoding for any cause (for example lack of
+memory or finding a split tar member at the beginning of a lzip member), it
+requests mastership to print an error and terminate the program. Only if
+some other worker requests mastership in a previous lzip member can this
+error be avoided.
+
+
+@node Multi-threaded decoding
 @chapter Limitations of parallel tar decoding
 @cindex parallel tar decoding
 
@@ -827,8 +941,8 @@ decoding it safely in parallel.
 Tarlz is able to automatically decode aligned and unaligned multimember
 tar.lz archives, keeping backwards compatibility. If tarlz finds a member
 misalignment during multi-threaded decoding, it switches to single-threaded
-mode and continues decoding the archive. Currently only the @samp{--list}
-option is able to do multi-threaded decoding.
+mode and continues decoding the archive. Currently only the options
+@samp{--diff} and @samp{--list} are able to do multi-threaded decoding.
 
 If the files in the archive are large, multi-threaded @samp{--list} on a
 regular (seekable) tar.lz archive can be hundreds of times faster than
@@ -843,6 +957,10 @@ time plzip -cd silesia.tar.lz | tar -tf -           (3.256s)
 time tarlz -tf silesia.tar.lz                       (0.020s)
 @end example
 
+On the other hand, multi-threaded @samp{--list} won't detect corruption in
+the tar member data because it only decodes the part of each lzip member
+corresponding to the tar member header.
+
 
 @node Minimum archive sizes
 @chapter Minimum archive sizes required for multi-threaded block compression
@@ -860,7 +978,7 @@ least as large as the number of worker threads times the block size
 compress, and compression will be proportionally slower. The maximum speed
 increase achievable on a given archive is limited by the ratio
 @w{(uncompressed_size / data_size)}. For example, a tarball the size of gcc
-or linux will scale up to 10 or 12 processors at level -9.
+or linux will scale up to 10 or 14 processors at level -9.
 
 The following table shows the minimum uncompressed archive size needed for
 full use of N processors at a given compression level, using the default