Date: Tue, 26 Aug 2014 22:54:56 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd current <freebsd-current@freebsd.org>, Chris H <bsd-lists@bsdforge.com> Subject: Re: did tar(1) loose xz compression support in 11? Message-ID: <Pine.GSO.4.64.1408262221340.8571@sea.ntplx.net> In-Reply-To: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> References: <cc981009f9a7332a7aad557c6a2ed216.authenticated@ultimatedns.net> <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Aug 2014, Tim Kientzle wrote:
>
> On Aug 26, 2014, at 11:05 AM, Chris H <bsd-lists@bsdforge.com> wrote:
>
>> Greetings,
>> I'm currently testing 11. My build / install is from about 2 days ago.
>> I generally use xz compression, when creating archives. But when I
>> attempt the following:
>>
>> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
>>
>> it returns the following:
>>
>> tar: Undefined option: `xz:9'
>>
>> This has always worked in previous versions. Has the syntax changed,
>> and the man(1) pages just haven't caught up?
>
> I can=92t see any evidence in libarchive=92s source that this ever worked=
=2E
The man page is a little confusing. Here it says:
--options options
Select optional behaviors for particular modules. The
argument is a text string containing comma-separated
keywords and values. These are passed to the modules that
handle particular formats to control how those formats will
behave. Each option has one of the following forms:
key=3Dvalue
The key will be set to the specified value in every
module that supports it. Modules that do not
support this key will ignore it.
Then below, after the last option, it says:
...
zip:compression=3Dtype
Use type as compression method. Supported values are
store (uncompressed) and deflate (gzip algorithm).
If a provided option is not supported by any module, that is a
fatal error.
The first states that it is ignored, the latter states that it
is a fatal error. The meaning of "any module" is subtle, at
least for my feeble brain ;-)
Also, the syntax for "[lr]zip:compression=3Dtype" is very clear,
whereas the syntax for compression-level keys omit the "=3Dvalue".
--=20
DE
From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 13:59:38 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 571D2CFF;
Wed, 27 Aug 2014 13:59:38 +0000 (UTC)
Received: from wonkity.com (wonkity.com [67.158.26.137])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "wonkity.com", Issuer "wonkity.com" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 029DD352B;
Wed, 27 Aug 2014 13:59:37 +0000 (UTC)
Received: from wonkity.com (localhost [127.0.0.1])
by wonkity.com (8.14.9/8.14.9) with ESMTP id s7RDxKL6061645
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Wed, 27 Aug 2014 07:59:20 -0600 (MDT)
(envelope-from wblock@wonkity.com)
Received: from localhost (wblock@localhost)
by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s7RDxJcX061630;
Wed, 27 Aug 2014 07:59:19 -0600 (MDT)
(envelope-from wblock@wonkity.com)
Date: Wed, 27 Aug 2014 07:59:19 -0600 (MDT)
From: Warren Block <wblock@wonkity.com>
To: Daniel Eischen <deischen@freebsd.org>
Subject: Re: did tar(1) loose xz compression support in 11?
In-Reply-To: <Pine.GSO.4.64.1408262221340.8571@sea.ntplx.net>
Message-ID: <alpine.BSF.2.11.1408270746550.46055@wonkity.com>
References: <cc981009f9a7332a7aad557c6a2ed216.authenticated@ultimatedns.net>
<134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com>
<Pine.GSO.4.64.1408262221340.8571@sea.ntplx.net>
User-Agent: Alpine 2.11 (BSF 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
(wonkity.com [127.0.0.1]); Wed, 27 Aug 2014 07:59:20 -0600 (MDT)
Cc: freebsd current <freebsd-current@freebsd.org>,
Chris H <bsd-lists@bsdforge.com>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>;
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 13:59:38 -0000
On Tue, 26 Aug 2014, Daniel Eischen wrote:
> On Tue, 26 Aug 2014, Tim Kientzle wrote:
>>
>> On Aug 26, 2014, at 11:05 AM, Chris H <bsd-lists@bsdforge.com> wrote:
>>
>>> Greetings,
>>> I'm currently testing 11. My build / install is from about 2 days ago.
>>> I generally use xz compression, when creating archives. But when I
>>> attempt the following:
>>>
>>> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
>>>
>>> it returns the following:
>>>
>>> tar: Undefined option: `xz:9'
>>>
>>> This has always worked in previous versions. Has the syntax changed,
>>> and the man(1) pages just haven't caught up?
>>
>> I can?t see any evidence in libarchive?s source that this ever worked.
>
> The man page is a little confusing. Here it says:
>
> --options options
> Select optional behaviors for particular modules. The
> argument is a text string containing comma-separated
> keywords and values. These are passed to the modules that
> handle particular formats to control how those formats will
> behave. Each option has one of the following forms:
>
> key=value
> The key will be set to the specified value in every
> module that supports it. Modules that do not
> support this key will ignore it.
>
>
> Then below, after the last option, it says:
>
> ...
> zip:compression=type
> Use type as compression method. Supported values are
> store (uncompressed) and deflate (gzip algorithm).
>
> If a provided option is not supported by any module, that is a
> fatal error.
>
> The first states that it is ignored, the latter states that it
> is a fatal error. The meaning of "any module" is subtle, at
> least for my feeble brain ;-)
It suggests that options are passed to all modules, and each module is
free to ignore options it does not understand. But at least one module
must understand the option, or a fatal error is reported.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1408262221340.8571>