XZ を TAR に変換

圧縮を外すというのは一見逆方向の作業に見えますが、それが唯一の正解になる場面があります。docker load は tarball から読み込みます。多くの機器や機器組み込み用の取り込みツールは、TAR ヘッダーを辿るように書かれたローダーがそのまま使われているため .tar を求めます。移行ツールも同様です。コンテンツアドレス指向のストレージの中には、1 ファイルの小さな変更でアーカイブ全体を書き換えたくないという理由で、圧縮していないバイト列を求めるものもあります。

中身をただ見たいだけの人もいます。tarball は展開の手順を挟まずに検査したり、差分を取ったり、スクリプトで辿ったり、tar --to-command に渡したりできます。1 つのアーカイブに午後の間何度も触るなら、圧縮を一度だけ外して最後にまた戻すという作業の仕方も合理的です。

XZ は 2009 年に登場し、LZMA2 で 1 本のストリームを圧縮します。ファイル名の欄も、フォルダーという概念も、1 つのメンバーがどこで終わるかを示す方法も持っていません。ディレクトリ構造を持たないことはこの形式のよく知られた課題として挙げられますが、それは欠陥というより設計上の割り切りです。

TAR は 1979 年生まれで POSIX.1-2001 ustar として標準化されており、ちょうどその裏返しです。各メンバーの前に 512 バイトのヘッダーがあり、名前、パス、サイズ、所有者、グループ、権限、タイムスタンプを記録し、圧縮はまったく行いません。両者を合わせて初めて仕事が完結するので、.tar.xz は回避策のように見えて実は本来の組み合わせです。この変換は外側の層を取り除いて、内側だけを渡します。

このサイトの他のアーカイブ変換にはたいてい容量に関する主張が含まれますが、ここでは逆です。事前に見込んでおく価値があります。ソースコードやログ、文書の XZ は数倍に膨らむことがあり、XZ の辞書サイズは最大 64 MB まで扱えるため、そもそもよく圧縮できていたぶん、展開後の tarball もそれだけ大きくなります。

実際の影響はすべて次にファイルがどこへ行くかにかかっています。XZ なら余裕で収まっていた添付ファイルの上限に収まらなくなります。ネットワーク越しのコピーにかかる時間もそれに比例して伸びます。空き容量が少ないノートパソコンでは、tarball を展開してからそれをまた展開するツールに渡す場合、中身を 3 重に保持することになります。どれもこの変換をやめる理由にはなりませんが、始める前に容量を把握しておく理由にはなります。

公開されたリリースを変換する人にとって、このページでいちばん重要な一文です。この変換は xz の層をただ剥がすのではなく、アーカイブを完全に展開してから、その中身をもとに新しい TAR を書き直します。中に入っているファイルはバイト単位で元と同一です。これは可逆な再パッケージだからです。ただし、それを包んでいる tarball そのものは元のものではありません。

そのため、リリースノートに載っている SHA-256 やパッケージレシピのハッシュ、tarball に対する署名は、ここでダウンロードしたものとは検証が通りません。検証が必要な作業なら、手元で xz -d archive.tar.xz を実行してください。これは外側の層だけに触れ、tarball を作者が書いたとおりのまま残します。このコンバーターは、tarball が存在すればよく、その正確なバイト列が契約の一部ではない場合に使ってください。中身の検分や取り込み、大半の一度きりの作業がそれにあたり、パッケージングはそれにあたりません。

TAR ヘッダーには所有者、グループ、権限ビット、更新時刻の欄があり、多くの tarball にとってそこは無視できない情報です。インストールスクリプトを含むリリースは、そのスクリプトが実行可能な状態で届くことに依存しており、コンテナイメージの tarball はさらに多くを前提にしています。TAR はそのすべてを運べる形式です。

この変換で実際に受け取るものは別の話です。「ファイルはバイト単位で同一だが、コンテナが中身について保持していた——中身そのものではない——情報は失われる危険がある」というのが、このサイトのアーカイブ変換すべてに共通する注意です。アーカイブは作業用ディレクトリに展開されてから再び tar 化されるため、権限と時刻はその往復で残ったものになります。tarball を docker load や、展開した内容を実行するものに渡すなら、事前に tar tvf でヘッダーの項目を確認してください。

すべての .xz が圧縮された tarball とは限りません。データベースのダンプやディスクイメージ、CSV の書き出しなど、大きな 1 つのファイルが単体で圧縮されていることも多く、その場合 tarball はどこにも存在しません。このコンバーターは両方に対応しています。ストリームを展開し、内側の TAR を取り出せるか試み、見つからなければ 1 つのファイルとして扱います。

その場合に得られるのは、メンバーが 1 つだけの TAR です。少し変わった形ですが正当なもので、後段のツールが求めている形であることも珍しくありません。診断としても役に立ちます。フォルダーの中身を期待していたのに 1 つのファイルが入っていたなら、元のファイルはそもそもアーカイブではなく、そう教えてくれた情報のほうが誤りだったことになります。XZ 自体はファイル名を持たないので、他に手がかりはありません。

xz のストリームを展開するには、ファイルが書かれたときの辞書サイズに応じたバッファーが必要で、最大で 64 MB になります。変換を行う機械にとってはたいした問題ではなく、めったに話題になりません。話題になるのは受け取る側です。圧縮を外したい理由が、非力な機器が XZ を開けないからだとしたら、この変換はより大きな転送量と引き換えに、その機器が読める形を渡す正当な方法です。

これは gzip や bzip2 へ再圧縮する方法とは別の道で、機器に十分な保存領域があり、そもそも圧縮ツールが何も入っていないとき——復旧環境やそぎ落とされたコンテナ、TAR ヘッダーを直接読んで外部プログラムを一切呼ばないインポーターなど——に正しい選択になります。機器に gzip があるなら、圧縮していない tarball より gzip 済みの tarball を送るほうがほとんどの場合良い結果になります。

ブラウザーの中ではなく、サーバー側で行われます。このサイトの多くのツールはファイルを端末に置いたまま処理すると案内していますが、アーカイブは例外です。7-Zip と xz という実プログラムが必要になる作業だからです。ファイルは暗号化された接続でコンテナに送られ、そのコンテナには自前の外部インターネット接続がありません。

各ジョブはメモリー上のスクラッチディレクトリを割り当てられ、結果にかかわらずジョブが終わり次第削除されます。処理は 60 秒で打ち切られます。書き込みが始まる前に、アーカイブが展開後にどれだけの容量になると宣言しているかが確認され、2 GB を超える申告は拒否されます。この確認はここでは特に重要です。この変換の出力は定義上「圧縮していないサイズ」だからです。無料枠は 1 ファイルあたり 25 MB までです。

tar tvf archive.tar を実行すると、すべてのメンバーの権限、所有者、サイズ、タイムスタンプが表示され、費用はかかりません。確認すべき点が 2 つあります。ひとつはトップレベルの構造です。あるディレクトリの中から詰めたアーカイブと、その親から詰めたアーカイブでは、すべてのパスの先頭にあるフォルダーの有無が違い、期待と違う形を受け取ったインポーターはファイルが見つからないというエラーで失敗します。

もうひとつは権限の列で、特にアーカイブの中に実行されるべきものがある場合です。TAR はモードビットを運べる数少ない形式のひとつなので、間違っていても直せます。展開して chmod してから tar し直すという手順を、自分の管理下にない機械で発見するより先に行っておいてください。一覧が正しく見えたら、その tarball は圧縮版を拒否した相手に渡す準備ができています。