RE: Is the xz format stable?
This is what the maintainer wants, in his own words:
We need a way to verify that a specific named version of xz, which might be
older than the version someone has installed, will be able to uncompress a
His main fear is that someone will create an xz file with a version of xz
which is newer than the version of xz that his project supports, and then
his project will not be able to read that file. However, your last
paragraph implies xz, including future versions, will create a file that is
unreadable by current versions of xz unless special parameters are used,
because to do otherwise would anger a lot of people. Is that true? If so,
I think it will help allay his fears.
Behalf Of Lasse Collin
Sent: Sunday, November 06, 2011 12:32 PM
Subject: Re: [xz-devel] Is the xz format stable?
On 2011-11-06 Tom Trauth wrote:
> Given an xz file,
> is there a way to determine which version of the xz format it uses.
> Something like:
> xz-get-version foo.xz --> foo.xz uses XZ format version 1.0.4
Right now there is no way to get a version number of the format.
I could make xz -lvv show the oldest XZ Utils version that will
decompress the file. It can only work for files that are supported by
the xz tool, so it's not possible to make an old xz tool to display how
much newer xz is required for a given file; the old tool could only tell
that it doesn't support it. I don't know if this could be good enough
To understand the reason for the above, it's good to understand how
incompatible additions may happen:
(1) A new filter/method ID may be added into the official .xz format
specification. Old tools will show that there is an unsupported
filter ID and cannot decompress such files (will display an error).
(2) Third-party developers may use custom filter IDs which aren't in
the official specification and aren't supported by XZ Utils. If
they don't deviate from the .xz specification in any other way,
this is OK. Old tools cannot distinguish this situation from (1).
(3) A new .xz format specification may add new features to the
container format. The old tools will detect such files as
unsupported (they won't claim them to be corrupt). With old tools,
the difference to (1) and (2) is that the old tools won't be able
to list even the filter IDs.
If incompatible additions are made, the xz tool won't use them by
default. Maybe they might become a default after several years have
passed and old xz versions aren't common anymore. But it won't be done
easily, because it would make people angry if the default settings
created files that many wouldn't be able to decompress without extra
Lasse Collin | IRC: Larhzu <at> IRCnet & Freenode