なぜ ezio か？

ezio は、Linux や UNIX を主要な環境として動作するアーカイバです。このドキュメントでは、ezio を使うメリットがどこにあるのか、言い換えると既存の archiver のどこに不足を感じたのか、そのあたりを見ていきたいと思います。

tar(pax, star)

標準的な tar は、巨大な file や Extended Attribute のような、現代的な需要に対応していないことがあります。pax や star などの拡張版は、tar ほど普遍的にインストールされていません。
tar 系の根本的な問題は、file を全て archive した後に compress/encrypt するところです。このため、archive の末尾に近い場所の file を取り出したくても、最初から全て decompress/decrypt していく必要があります(厳密には、必ずしもそうではないこともある)。
同様の理由で、archive の一部が破損したり失われたりすると、そこよりも後の file が取り出せなくなる可能性があります。
compress/encrypt を外部ツールに頼っていて、gzip/bzip2/xz のような例外は別として、暗号や署名に標準的な作法が定まっていません。このため外部ツール選択の自由がある反面、archive file を他人に渡すだけでは済まず、手順や別 file も渡す必要が出てきます。
tar は POSIX で規格が定義されていて、さまざまな環境、さまざまなシナリオで使えるという利点があります。また、archive の後に compress することから、afio や ezio のような file 単位の処理よりも良い圧縮率が期待できます。
オプションが多すぎます。

afio

cpio 系の afio は完全に static な header を持ち、拡張が困難です。
特に問題となるのは、metadata の暗号化や、Extended Attribute に対応するのが不可能な点です。独自に拡張してしまうと、afio と互換性を失ってしまいます。
data の暗号化は一応は可能ですが、外部ツールに頼ることから tar 系と同様の問題を抱えます。
afio の弱点は static な header ですが、逆に decode が容易という利点でもあります。decoder を作成するのは簡単ですし、構造が簡単ゆえにバグも発生しにくいです。
オプションが多すぎます。

dar

dar は tar の拡張の一つ思われがちですが、file ごとに compress/encrypt するという点では afio と同様です。
署名や消失訂正符号を除いて、各種機能への対応は非常に良いです。
backup tool としての性格が強く、高機能すぎて、archiver として使おうとすると少し難しいです。
オプションが多すぎます。

WinRAR

WinRAR は Windows では標準的ですが、UNIX 対応が進んだのが比較的最近であるため、それほど使われていません。
symbolic/hard link に対応していますし、uid/gid も保存します。一般的なユーザーの一般的な用途としては充分に UNIX 上で使えます。
圧縮率や速度は良好な性能で、暗号化も自前で処理します。Quick Open や Recovery Record といった機能もあり、非常に優れた archiver です。
WinRAR の問題はライセンスです。家に Raspberry Pi が何台かあって、クラウド上に少しばかりの仮想環境が存在するような良くある環境であっても、ホスト数ベースのライセンスはナンセンスです。

その他 Windows 用 archiver

Windows の世界では WinRar 以外にも 7-zip を初めとして優れた archiver が存在して、そのうちのいくつかは UNIX でも動作しますが、残念ながら実用的なレベルで対応しているものは、ほとんどありません。

ezio

file 単位で圧縮・暗号化を処理するため、特定の file の取り出しが効率的です。
同様の理由で、破損した archive の未破損部分を取り出すことも容易です。
自前で圧縮・暗号化・署名を処理するため、外部ツールが必要ありません。
filename や size のような metadata も全て暗号化できます。
認証付き暗号を使っていて、archive の改竄に耐性があります。
圧縮アルゴリズムの標準が、高速かつ良圧縮の zstd です。
消失訂正符号を付加できて、ある程度までの破損を修復できます。
metadata のみの list を archive 末尾に付加できて、これにより高速に file list を取得できます。
Linux の Extended Attribute に対応していて、SELinux や capability といった属性も保存できます。
フォーマットが論理的な意味で XML ライクで、互換性を保ったままの拡張がある程度可能です。
Go 言語で書かれていて、改造が容易です。
必要最低限のオプションしか用意されていないため、簡単に使えます。
現時点では、充分にテストされていません。
エラー等のイレギュラーに対して、少し弱いところがあります。
compression rate や speed は、重要ではありますが、1st priority ではありません。
Go 言語で記述されているため、速度的に C/C++ で最適化したコードに及びません。とはいえボトルネックは I/O だったり、圧縮や暗号化だったりするので、どの程度 Go だから不利なのかと言われると、なんとも。なお zstd/lz4/xz などは C ライブラリを利用しています。
フォーマットが論理的な意味で XML ライクで、encode/decode が少し重く、相対的にバグが入り込みやすいです。

参考リンク