tar-1.22.90 released

[Sergey Poznyakoff-2]

Hello,

New alpha release of GNU tar, tar-1.22.90, is available for download
from ftp://alpha.gnu.org/gnu/tar.  See below for the list of new
features and bugfixes.

Please, test it.  Any reports and suggestions are much appreciated.

Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.tar.gz    (3.0MB)
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.tar.bz2   (2.0MB)
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.cpio.gz   (3.0MB)
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.shar.gz   (4.5MB)

Here are the GPG detached signatures[*]:
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.tar.gz.sig
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.cpio.gz.sig
  ftp://alpha.gnu.org/gnu/tar/tar-1.22.90.shar.gz.sig

Here are the MD5 and SHA1 checksums:

499cceb9d2c2b02421ee08e2e61fb233          tar-1.22.90.tar.gz
f6e373e498b3fe7d86547d0035573579          tar-1.22.90.tar.bz2
6af956ca1aad9b246523c4ab6c595f50          tar-1.22.90.cpio.gz
20f46726096d3a2ea0a72a5b2ffb460e          tar-1.22.90.shar.gz
84439222687eccf6c4bf8da467d428b1b4033faa  tar-1.22.90.tar.gz
ff2d6fd280f891131e62ed4e22c8ca2828eced56  tar-1.22.90.tar.bz2
f82ce89a48548f9f4b0216dcf5c600e40e5f483a  tar-1.22.90.cpio.gz
5a4248ba175afa1c123d6bc58c7974e53989a668  tar-1.22.90.shar.gz

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify tar-1.22.90.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 55D0C732

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.63
  Automake 1.11
  Gnulib-tool 0.0.2273-2bab1
  Makeinfo 4.13

The list of user-visible changes follows:

* Record size autodetection

When listing or extracting archives, the actual record size is
reported only if the archive is read from a device (as opposed
to regular files and pipes).

* New command line option `--warning'

The `--warning' command line option allows to suppress or enable
particular warning messages during `tar' run.  It takes a single
argument (a `keyword'), identifying the class of warning messages
to affect.  If the argument is prefixed with `no-', such warning
messages are suppressed.  For example,

  tar --warning=no-alone-zero-block -x -f archive

suppresses the output of `A lone zero block' diagnostics, which is
normally issued if `archive' ends with a single block of zeros.

* New command line option `--level'

The `--level=N' option sets the incremental dump level N.  It
is valid when used in conjunction with the -c and --listed-incremental
options.  So far the only meaningful value for N is 0.  The
`--level=0' option forces creating the level 0 dump, by truncating
the snapshot file if it exists.

* Files removed during incremental dumps

If a file or directory is removed while incremental dump is
in progress, tar exact actions depend on whether this file
was explicitly listed in the command line, or was gathered
during file system scan.

If the file was explicitly listed in the command line, tar
issues error message and exits with the code 2, meaning
fatal error.

Otherwise, if the file was gathered during the file system
scan, tar issues a warning, saying "File removed before we read it",
and sets the exit code to 1, which means "some files differ".
If the --warning=no-file-removed option is given, no warning
is issued and the exit code remains 0.

* Bugfixes
** Fix handling of hard link targets by -c --transform.
** Fix hard links recognition with -c --remove-files.
** Fix restoring files from backup (debian bug #508199).
** Correctly restore modes and permissions on existing directories.

Regards,
Sergey

[Eric Blake]

Sergey Poznyakoff <gray <at> gnu.org.ua> writes:

> New alpha release of GNU tar, tar-1.22.90, is available for download
> from ftp://alpha.gnu.org/gnu/tar.  See below for the list of new
> features and bugfixes.

Can you please push the signed release tag to tar.git to reflect this release?

Also, it would be nice if you considered using git submodules, to make it
easier to definitively track which commit of gnulib.git and paxutils.git you
used when building tar releases.  Otherwise, comments like "The new testcases
require paxutils commit f653a2b or later" in commit 51aee27 are harder to
enforce.

--
Eric Blake

[Sergey Poznyakoff-2]

Eric Blake <ebb9@...> ha escrit:

> Can you please push the signed release tag to tar.git to reflect this release?

OK

> Also, it would be nice if you considered using git submodules, to make it
> easier to definitively track which commit of gnulib.git and paxutils.git you
> used when building tar releases.  Otherwise, comments like "The new testcases
> require paxutils commit f653a2b or later" in commit 51aee27 are harder to
> enforce.

It's not critical to "enforce" it. The README-hacking says clearly that
we "do not make any efforts to accommodate older versions of
these packages", so that anybody wanting to fiddle with the git version
knowns he should always have latest versions around.

Regards,
Sergey

[Eric Blake]

Sergey Poznyakoff <gray <at> gnu.org.ua> writes:

> > Also, it would be nice if you considered using git submodules, to make it
> > easier to definitively track which commit of gnulib.git and paxutils.git
you
> > used when building tar releases.
>
> It's not critical to "enforce" it. The README-hacking says clearly that
> we "do not make any efforts to accommodate older versions of
> these packages", so that anybody wanting to fiddle with the git version
> knowns he should always have latest versions around.

That's true when developing on top of the latest commit on upstream tar.git.  
But it is not the case when trying to recreate the state of an older label.  
For example, with coreutils, it is possible to 'git checkout v7.4; ./bootstrap'
and have the gnulib submodule automatically reverted back to the proper commit
that was in use at the time coreutils 7.4 was cut, even though gnulib has since
changed; this is particularly handy when you realize that some of the changes
in current gnulib.git (such as those to maint.mk) are incompatible with the
contents of coreutils.git back in the 7.4 days.

In other words, submodules are a nice way of documenting what has been tested
to work, rather than making the developer manually guess which commit to use in
paxutils.git and gnulib.git when playing with an older version of tar.git.  It
also means that 'git bisect' can be more powerful at automating a regression
hunt.

--
Eric Blake