0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

tarがあるのにPAFを作った理由

Posted at

はじめに

「tarで良いのでは?」

PAFについて投稿したところ、そういったコメントをいただきました。
正直、私自身も「tarで良い」と思っていたし、今でもtarはよく使っています。

それでも私は、新しいアーカイブ形式 PAF(Parallel Archive Format) を作りました。
なぜtarがあるのに、わざわざPAFを作ったのか?
本記事では、それでもPAFを開発した理由と設計思想を紹介します。


「tarで良い」と思っていた

まず最初に、tarは非常に優秀です。

  • UNIX/Linuxに標準搭載
  • 圧縮(gzip / xz / bzip2)との併用
  • 所有者・パーミッション・mtimeも保存
  • スクリプトとの相性も良好
  • 最近の実装はUTF-8対応も進んでいる

アーカイブ形式として、tarはすでに完成されています。
だからこそ、最初にPAFを作ろうとしたときに思ったのは:

「tarでいいのでは?」


それでもPAFを作った理由

🔧 最初は「作ってみたかった」から始まった

正直に言えば、最初はtarの代替を作るつもりではありませんでした
ただ、アーカイブ形式を自分で作ってみたい、という思いがありました。

  • バイナリ形式を自分で設計・実装してみたい
  • 展開が爆速なアーカイブを試したい
  • .gitignore のような除外ルールを組み込んでみたい

そうしたエンジニアとしての好奇心や創作意欲から、PAFの構想は始まりました。


🧭 でも作っていく中で「tarを拡張するより、ゼロからの方がいい」と思った

最初は、tarをGUIやブラウザで扱えるようにする構想も考えていました
ですが、実際に対応すべき要件を洗い出していく中で課題が見えてきました。

  • 全OS対応(Windows/macOS/Linux)
  • 文字コードの一貫性(UTF-8前提)
  • パーミッションや所有者情報の影響を排除したい
  • パストラバーサル対策を含めた安全な展開
  • GUIやWASM上で展開可能なファイル構造

こうした要件を1つ1つ丁寧に満たしていくには、既存のtarベースよりも、
ゼロから設計したほうがシンプルで安全
だと判断しました。

結果として、PAFは「技術的にも、構造的にもtarとは異なる道を選んだ」形式になりました。


💡 それでもzip / tarでは満たしきれなかったポイントもあった

  • zip:展開せずに中身を直接開いて上書きしてしまう事故が多発
  • tar:ロケールや実装によってUTF-8文字化けが起きる
  • 両者とも、.gitignore のような除外ルールに非対応
  • 単一ファイル抽出でも全体走査が必要(大容量になると非効率)
  • 所有者・パーミッション・mtimeの復元が意図しない動作を生むことも

zip / tar / paf の違い

以下に、よく使われる .zip, .tar, .paf の3つのアーカイブ形式の比較を示します。

項目 .zip .tar .paf
圧縮対応 ✔(デフォルトで圧縮) ❌(圧縮は別途) ❌(非対応)
非圧縮時の展開速度 △(ZIP構造が複雑) △(逐次走査) ◎(爆速:生バイナリ)
UTF-8対応 △(実装依存) △(ロケール・実装依存) ◎(UTF-8固定)
.gitignore 互換除外 ◎(.pafignore, --ignore-from
部分抽出の効率 △(ZIP構造による) ❌(全体走査) ◎(インデックス構造)
所有者・パーミッション保存 △(一部対応) ◎(完全対応) ❌(あえて非対応)
CRCチェック ✔(ZIP標準) ◎(各ファイルにCRC32)
トラバーサル保護 実装依存 ◎(明示的に対策済)
GUI/ブラウザ展開 ◎(OS標準) ◎(WASM・GUI設計中)
スクリプト互換性 ○(C API / Python CLI)
向いている用途 一般的な圧縮共有 バックアップ・構成管理 高速配布・安全展開・GUI統合向け

PAFの特徴と構造

🎯 特徴まとめ

  • 非圧縮:そのまま書き出し、展開爆速
  • UTF-8固定:どのOSでも文字化けなし
  • インデックス付き:ファイル一覧や抽出が高速
  • .pafignore 対応:除外ルール標準装備
  • CRC32:整合性チェック
  • トラバーサル対策 / 上書き保護:安全な展開
  • Cライブラリ / Python / WASM(予定):多言語・GUIでの統合

UNIX属性をあえて「持たない」理由

PAFは、以下のような情報を保存しません:

  • 所有者(user / group)
  • 実行権限・パーミッション
  • タイムスタンプ(mtime)
  • ハードリンク・シンボリックリンク

その理由:

PAFは再現性の高いバックアップ用途ではなく、
環境を問わず安全・高速に展開できる配布用アーカイブを目指しているためです。

  • 所有者属性が意図せず上書きされるリスクを防止
  • CI/CDやGUI環境でパーミッションに左右されずに展開できる
  • 中身にだけ注目して、最小構成で済ませたい用途に適している

想定ユースケース

  • 成果物やツールの高速配布(再展開不要)
  • GUIツールやブラウザでのファイル閲覧(WASMビューワ対応予定)
  • .gitignore 互換の除外付きアーカイブ作成
  • 展開中の事故を避けたいシステム

おわりに

「tarで良いのでは?」という声。
私も本当に同じように思っていました。

それでも、
tarとは違う方向からアーカイブを考えてみたくなった。
そして、自分の願望を形にしたPAFを作りました。

tarで良いのは間違いありません。
私も何かしらでアーカイブ化が必要になったらtarを使うと思います。
でも、tarとは別のアプローチもあっていい。

PAFが何か1つでも、現場での「あ、こういうの欲しかった」に届けばうれしいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?