Loading article…
Parchive（parity archiveの略で、正式にはParity Volume Set Specification [ 1 ] [ 2 ]として知られています）は、データの整合性のチェックサム検証のためにparファイルを生成する消去コードシステムであり、破損または欠落したデータを修復または再生成できるデータ復旧操作を実行する機能を備えています。
Parchiveは元々 Usenetでの信頼性の高いファイル共有の問題を解決するために書かれたものですが[ 3 ]、あらゆる種類のデータをデータ破損、ディスク腐敗、ビット腐敗、偶発的または悪意のある損傷から保護するために使用できます。名前とは裏腹に、Parchiveは単純なパリティ方式のエラー検出よりも高度な技術（特にエラー訂正コード）を使用しています。
2015 年現在、PAR1は廃止され、PAR2 は広く使用できるほど成熟しており、PAR3 はMultiPar の作者である澤田豊氏によって開発された、開発が中止された実験版です。[ 4 ] [ 5 ] [ 6 ] [ 7 ] オリジナルのSourceForge Parchive プロジェクトは、2015 年 4 月 30 日以降、活動していません。[ 8 ] PAR2 仕様の作者である Michael Nahas 氏が 2019 年 4 月 28 日以降、新しい PAR3 仕様に取り組んでいます。PAR3 仕様のアルファ版は、プログラム自体が開発されている間に、2022 年 1 月 29 日に公開されました。[ 9 ]
ParchiveはUsenetニュースグループを介したファイルの転送の信頼性を向上させることを目的としていました。Usenetは元々非公式な会話のために設計されており、基盤となるプロトコルであるNNTPは任意のバイナリデータを送信するようには設計されていませんでした。会話には許容範囲でしたがファイルには許容できなかったもう1つの制限は、メッセージの長さが通常かなり短く、7ビットASCIIテキストに限定されていたことです。[ 10 ]
Usenet 上でファイルを送信するために、 uuencodingやBase64など、さまざまな技術が考案されました。後の Usenet ソフトウェアでは 8 ビット拡張 ASCIIがサポートされ、 yEncなどの新しい技術が可能になりました。大きなファイルは分割され、ダウンロードの破損による影響を軽減しましたが、Usenet の信頼性の低さは依然として残りました。
Parchiveの導入により、パリティファイルを作成し、元のデータファイルと一緒にアップロードできるようになりました。Usenetサーバー間でデータファイルが転送される際に破損または紛失した場合、ユーザーはパリティファイルをダウンロードして、破損または紛失したファイルを復元できます。Parchiveには、復元データを含まない小さなインデックスファイル（バージョン1では*.par、バージョン2では*.par2）の作成機能も含まれていました。これらのインデックスには、対象ファイルを迅速に識別し、ファイルの整合性を確認するために使用できるファイルハッシュが含まれています。
インデックスファイルは非常に小さかったため、データファイルがすべて存在し、破損していないことを検証したり、破損を修復したり、欠落したファイルを再構築するために必要なパリティボリュームの数を判断したりするために、Usenet からダウンロードする必要のある追加データの量を最小限に抑えることができました。これらは、パリティボリュームが短いインデックスファイルよりもはるかに大きかったバージョン 1 で最も役立ちました。これらの大きなパリティボリュームには、実際のリカバリデータとインデックスファイルの情報の複製コピーが含まれています (これにより、小さなインデックスファイルが利用できない場合でも、データファイルの整合性を検証するために単独で使用できます)。
2001 年 7 月、Tobias Rieper と Stefan Wehlus は Parity Volume Set 仕様を提案し、他のプロジェクト メンバーの協力を得て、2001 年 10 月に仕様のバージョン 1.0 が公開されました。[ 11 ] Par1 は、 Reed–Solomon エラー訂正を使用して新しいリカバリ ファイルを作成しました。リカバリ ファイルのいずれかを使用して、不完全なダウンロードから欠落したファイルを再構築できます。
バージョン1はUsenetで広く使われるようになったが、いくつかの制限があった。
2002 年 1 月、ハワード・フカダは、データ検証と修復はファイル全体ではなくデータブロックに対して行うべきであり、アルゴリズムは PAR1 で使用されていた 8 ビット数ではなく 16 ビット数を使用するように切り替えるべきであるという重要な変更を加えた新しい Par2 仕様を考案すべきだと提案した。マイケル・ナハスとピーター・クレメンツは、2002 年 7 月にこれらのアイデアを取り上げ、ポール・ネトルとライアン・ギャラガー (両者とも Par1 クライアントを作成した) からの追加的な意見も得た。Parchive 仕様のバージョン 2.0 は、マイケル・ナハスによって 2002 年 9 月に公開された。[ 14 ]
ピーター・クレメンツはその後、最初の2つのPar2実装であるQuickParとpar2cmdlineを作成しました。2004年以降開発が中断されていたため、ポール・ホウルがpar2cmdlineの後継としてphpar2を作成しました。また、澤田豊はQuickParの後継としてMultiParを作成しました。MultiParは、バックエンドエンジンとしてpar2j.exe（par2cmdlineの最適化技術を部分的にベースとしている）を使用しています。
ファイル形式のバージョン1とバージョン2には互換性がありません。（ただし、多くのクライアントは両方をサポートしています。）
Par1 の場合、ファイルf1、f2、...、fn からなる Parchive は、リカバリ ブロックのない CRC タイプのファイルであるインデックスファイル ( f.par ) と、複数の「パリティ ボリューム」( f.p01、f.p02など) で構成されます。1 つのオリジナル ファイル (たとえばf2 ) を除くすべてのオリジナル ファイルがある場合、他のすべてのオリジナル ファイルと任意のパリティ ボリュームのいずれか 1 つがあれば、不足しているf2を作成できます。あるいは、任意の 2 つのパリティ ボリュームから不足している 2 つのファイルを再作成するなど、同様のことが可能です。[ 15 ]
Par1は、最大256個のソースファイルとリカバリファイルをサポートします。
Par2 ファイルは通常、filename.vol000+01.PAR2、filename.vol001+02.PAR2、filename.vol003+04.PAR2、filename.vol007+06.PAR2などの命名/拡張子システムを使用します。ファイル名の「+」の後の数字は、そのファイルに含まれるブロックの数を示し、「vol」の後の数字は、PAR2 ファイル内の最初のリカバリ ブロックの番号を示します。ダウンロードしたインデックス ファイルに 4 つのブロックが欠落していると記載されている場合、ファイルを修復する最も簡単な方法は、filename.vol003+04.PAR2をダウンロードすることです。ただし、冗長性があるため、filename.vol007+06.PAR2も使用できます。インデックス ファイルfilename.PAR2もあり、これは PAR1 で使用される小さなインデックス ファイルと機能は同じです。
Par2仕様では、最大32,768個のソースブロックと最大65,535個のリカバリブロックをサポートしています。入力ファイルは複数の等しいサイズのブロックに分割されるため、リカバリファイルは最大の入力ファイルのサイズと同じである必要はありません。
UnicodeはPAR2の仕様書ではオプションとして記載されているものの、ほとんどのPAR2実装はUnicodeをサポートしていない。
ディレクトリのサポートはPAR2仕様に含まれていますが、ほとんど、あるいはすべての実装ではサポートされていません。
Par3仕様は当初、Par2仕様の改良版として公開される予定だった。しかし、現在に至るまで、仕様の所有者である澤田豊氏によって非公開のままとなっている。
2019年1月29日、メンテナンスされているフォークpar2cmdlineのGitHubイシューセクションで、新しいフォーマットに関する議論が始まりました。この議論の結果、Par3という新しいフォーマットが誕生しました。新しいPar3フォーマットの仕様はGitHubで公開されていますが、2022年1月28日現在、アルファ版ドラフトのままです。この仕様は、Par2仕様の著者であるMichael Nahas氏が、Yutaka Sawada氏、animetosho氏、malaire氏の協力を得て作成しました。
新しいフォーマットは、Par2フォーマットに比べて以下のような複数の利点があると謳っている。
このプロジェクトの当初のアイデアは、RAIDのようなシステムのデータ復旧機能の概念をUsenet上のマルチパートアーカイブの投稿と復旧に適用するツールを提供することでした。