パーアーカイブ

パーアーカイブ
ファイル名拡張子
.par、.par2、.p??、(.par3 将来)
フォーマットの種類消去コードアーカイブファイル

Parchiveparity archive略語で、正式にはParity Volume Set Specification [ 1 ] [ 2 ])は、データ整合性のチェックサム検証用のparファイルを生成する消失訂正符号システムであり、破損または欠落したデータを修復または再生できる データ回復操作を実行する機能を備えています。

Parchiveは元々 、Usenet上での信頼性の高いファイル共有の問題を解決するために開発されましたが[ 3 ] 、あらゆる種類のデータをデータ破損ディスクの劣化ビットの劣化、そして偶発的または悪意のある損傷から保護するために使用できます。その名前にもかかわらず、Parchiveは単純なパリティ方式によるエラー検出よりも高度な技術(特にエラー訂正コード)を使用しています。

2014年現在、PAR1は廃止され、PAR2は広く使用できるほど成熟しており、PAR3はMultiParの作者である澤田豊氏によって開発された中止された実験版である。[ 4 ] [ 5 ] [ 6 ] [ 7 ] オリジナルのSourceForge Parchiveプロジェクトは2015年4月30日以来非アクティブになっている。[ 8 ]新しいPAR3仕様は、PAR2仕様の作者であるMichael Nahas氏によって2019年4月28日から作業が行われている。PAR3仕様のアルファ版は、プログラム自体の開発が行わ れている2022年1月29日に公開された[ 9 ] 。

歴史

Parchiveは、Usenetニュースグループを介したファイル転送の信頼性を向上させることを目的としていました。Usenetはもともと非公式な会話のために設計されたものであり、基盤となるプロトコルであるNNTPは任意のバイナリデータを転送するようには設計されていませんでした。会話には許容されていたもののファイルには許容されなかったもう一つの制限は、メッセージの長さが通常かなり短く、7ビットASCIIテキストに制限されていたことです。[ 10 ]

Usenet経由でファイルを送信するために、 uuencodingBase64など、様々な技術が考案されました。その後、Usenetソフトウェアは8ビット拡張ASCIIに対応し、yEncなどの新しい技術も利用可能になりました。大きなファイルは、ダウンロード時の破損の影響を軽減するために分割されましたが、Usenetの信頼性の低さは依然として残りました。

Parchiveの導入により、パリティファイルを作成し、元のデータファイルと共にアップロードできるようになりました。Usenetサーバー間で伝播中にデータファイルが破損または消失した場合、ユーザーはパリティファイルをダウンロードして、破損または消失したファイルを復元できます。Parchiveには、復元データを含まない小さなインデックスファイル(バージョン1では*.par、バージョン2では*.par2)の作成機能も含まれています。これらのインデックスにはファイルハッシュが含まれており、これにより対象ファイルを迅速に識別し、整合性を検証することができます。

インデックスファイルは非常に小さかったため、データファイルがすべて存在し、破損していないことを確認するために、あるいは破損を修復したり欠落したファイルを再構築したりするために、Usenetからダウンロードしなければならない余分なデータの量を最小限に抑えることができました。インデックスファイルは、パリティボリュームが短いインデックスファイルよりもはるかに大きかったバージョン1で最も役立ちました。これらの大きなパリティボリュームには、実際のリカバリデータに加えて、インデックスファイル内の情報の複製コピーが含まれています(これにより、小さなインデックスファイルがない場合でも、パリティボリュームだけでデータファイルの整合性を検証できます)。

2001年7月、トビアス・リーパーとステファン・ウェールスはパリティ・ボリューム・セット仕様を提案し、他のプロジェクトメンバーの協力を得て、2001年10月にバージョン1.0の仕様が公開されました。[ 11 ] Parity Volume Setはリード・ソロモン誤り訂正を用いて新しいリカバリファイルを作成しました。これらのリカバリファイルはいずれも、不完全なダウンロードから失われたファイルを再構築するために使用できます。

バージョン 1 は Usenet で広く使用されるようになりましたが、いくつかの制限がありました。

  • 最大 255 ファイルまでしか処理できないように制限されていました。
  • リカバリファイルは最大の入力ファイルと同じサイズである必要があったため、入力ファイルのサイズが一定でない場合はうまく機能しませんでした。(そのため、独自のRAR圧縮ツールと併用しない場合は、その有用性が制限されていました。)
  • 回復アルゴリズムにはバグがありましたが、これはその元となった学術論文[ 13 ]の欠陥[ 12 ]によるものでした。
  • これは Usenet と強く結びついており、より一般的なツールであればより幅広いユーザーが利用できる可能性があると考えられていました。

2002年1月、ハワード・フカダは、データの検証と修復をファイル全体ではなくデータブロック単位で行うこと、そしてアルゴリズムをPAR1で使用していた8ビットではなく16ビットに変更するという重要な変更を加えた新しいPar2仕様を考案することを提案した。マイケル・ナハスとピーター・クレメンツは2002年7月にこのアイデアを採用し、ポール・ネトルとライアン・ギャラガー(両者ともPar1クライアントを開発した)からの情報も取り入れた。Parchive仕様のバージョン2.0は、マイケル・ナハスによって2002年9月に公開された。[ 14 ]

その後、Peter Clementsは最初の2つのPar2実装、QuickParとpar2cmdlineを開発しました。2004年に廃止されたphpar2は、Paul Houleがpar2cmdlineの後継として開発しました。Yutaka SawadaはQuickParの後継としてMultiParを開発しました。MultiParは、par2cmdlineの最適化技術を部分的にベースとしたpar2j.exeをバックエンドエンジンとして利用しています。

バージョン

ファイル形式のバージョン 1 と 2 には互換性がありません。(ただし、多くのクライアントは両方をサポートしています。)

パー1

Par1の場合、ファイルf1f2、…、fn、Parchiveは、リカバリブロックのないCRC形式のインデックスファイル( f.par )と、複数の「パリティボリューム」( f.p01f.p02など)で構成されます。1つ(例えばf2 )を除くすべてのオリジナルファイルがあれば、他のすべてのオリジナルファイルと任意のパリティボリュームがあれば、失われたf2を作成できます。あるいは、任意の2つのパリティボリュームから失われた2つのファイルを再作成することも可能です。[ 15 ]

Par1 は、最大合計 256 個のソース ファイルとリカバリ ファイルをサポートします。

パー2

PAR2ファイルは通常、次のような命名/拡張子システムを使用します:filename.vol000+01.PAR2filename.vol001+02.PAR2filename.vol003+04.PAR2filename.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 仕様に含まれていますが、ほとんどまたはすべての実装ではサポートされていません。

パー3

Par3仕様は当初、Par2仕様の拡張版として公開される予定でした。しかし、現在まで仕様オーナーである澤田豊氏によってクローズドソースのままとなっています。

2019年1月29日、メンテナンス中のフォークpar2cmdlineのGitHub Issueセクションで、新しいフォーマットに関する議論が開始されました。この議論から、Par3とも呼ばれる新しいフォーマットが生まれました。新しいPar3フォーマットの仕様はGitHubで公開されていますが、2022年1月28日現在、アルファドラフトのままです。この仕様は、Par2仕様の著者であるMichael Nahas氏が、Yutaka Sawada氏、animetosho氏、malaire氏の協力を得て作成しました。

新しいフォーマットは、以下のサポートを含め、Par2 フォーマットに比べて複数の利点があると主張しています。

  • ファイル数が 2 16 個以上、ブロック数が 2 16個以上。
  • 小さなファイルを 1 つのブロックにまとめ、ブロックが複数のファイルに出現する場合は重複を排除します。
  • UTF-8ファイル名。
  • ファイルの権限、ハード リンク、シンボリック/ソフト リンク、空のディレクトリ。
  • ZIP アーカイブISO ディスク イメージなどの他の形式内に PAR データを埋め込む。
  • 「増分バックアップ」では、ユーザーが一部のファイルまたはフォルダーの回復ファイルを作成し、一部のデータを変更し、古いファイルの一部を再利用して新しい回復ファイルを作成します。
  • より多くのエラー訂正コードアルゴリズム( LDPCスパースランダムマトリックスなど)。
  • BLAKE3ハッシュ。PAR2で使用されるMD5ハッシュのサポートを廃止しました。

ソフトウェア

マルチプラットフォーム

ウィンドウズ

  • MultiPar (フリーウェア) — QuickParの機能とGUIを基盤とし、PAR2バックエンドとしてYutaka Sawada氏のpar2j.exeを使用しています。MultiParはUnicodeで複数の言語をサポートしています。MultiParという名前は「多言語PARクライアント」に由来しています。MultiParはTrueOSUbuntuWineでも動作することが確認されており、他のオペレーティングシステムでも動作する可能性があります。[ 16 ] [ 17 ] Par2コンポーネントはオープンソースです(またはオープンソースになる予定です)。しかし、その上に構築されているMultiParのGUIは現在オープンソースではありません。[ 18 ]
  • QuickPar (フリーウェア) — 2004 年以降メンテナンスされておらず、MultiPar に置き換えられました。
  • phpar2  — マルチスレッドと高度に最適化されたアセンブラコードを備えた高度な par2cmdline (QuickPar 0.9.1 より約 66% 高速)
  • ミラー — 最初の PAR 実装。2001 年以降メンテナンスされていません。

マックOSX

POSIX

POSIX準拠のオペレーティング システム 用のソフトウェア:

参照

参考文献

  1. ^ Re: Wikipedia の Parchive の訂正、返信 #3、Yutaka Sawada さん:「正式なタイトルは「Parity Volume Set Specification 1.0」と「Parity Volume Set Specification 2.0」です。」
  2. ^ Re: Wikipedia の Parchive の訂正、返信 #3、Yutaka Sawada さん:「正式なタイトルは「Parity Volume Set Specification 1.0」と「Parity Volume Set Specification 2.0」です。」
  3. ^ 「Parchive: Parity Archive Volume Set」 。 2009年10月29日閲覧このプロジェクトの当初のアイデアは、RAIDのようなシステムのデータ復旧機能の概念を、Usenet上の複数パートのアーカイブの投稿と復旧に適用するためのツールを提供することでした。
  4. ^ 「新しいPAR3ファイルの可能性」。2012年7月7日時点のオリジナルよりアーカイブ2012年7月1日閲覧。
  5. ^ 「PAR3の使用に関する質問」。2014年3月9日時点のオリジナルよりアーカイブ2012年7月1日閲覧。
  6. ^ 「検出不可能な意図的な改変のリスク」。2014年3月9日時点のオリジナルよりアーカイブ2012年7月1日閲覧。
  7. ^ 「PAR3仕様提案は2011年4月時点で未完成」。2014年3月9日時点のオリジナルよりアーカイブ2012年7月1日閲覧。
  8. ^ 「Parchive: Parity Archive Tool」 . 2015年4月30日. 2020年5月20日閲覧
  9. ^ 「パリティボリュームセット仕様 3.0 [2022-01-28 アルファドラフト]」。Michael Nahas、Yutaka-Sawada、animetosho、malaire。
  10. ^ Kantor, Brian; Lapsley, Phil (1986年2月). 「文字コード」 . Network News Transfer Protocol . IETF . p. 5. sec. 2.2. doi : 10.17487/RFC0977 . RFC 977. 2009年10月29日閲覧
  11. ^ Nahas, Michael (2001-10-14). 「パリティボリュームセット仕様 v1.0」 . 2017年6月19日閲覧
  12. ^ Plank, James S.; Ding, Ying (2003年4月). 「注記:1997年のリード・ソロモン符号化チュートリアルの訂正」 . 2009年10月29日閲覧
  13. ^ Plank, James S. (1997年9月). 「RAID系システムにおけるフォールトトレランスのためのリード・ソロモン符号化チュートリアル」 . 2009年10月29日閲覧
  14. ^ Nahas, Michael; Clements, Peter; Nettle, Paul; Gallagher, Ryan (2003-05-11). 「パリティボリュームセット仕様 2.0」 . 2009年10月29日閲覧
  15. ^ Wang, Wallace (2004-10-25). 「映画(またはテレビ番組)を探す:PARファイルとPAR2ファイルを使ったRARファイルの復元」 . Steal this File Sharing Book (第1版).サンフランシスコ、カリフォルニア州: No Starch Press . pp.  164–167 . ISBN 978-1-59327-050-6. 2009年9月24日閲覧
  16. ^ 「MultiParはPCBSD 9.0で動作します」。2013年9月28日時点のオリジナルよりアーカイブ2012年2月27日閲覧。
  17. ^ Wine経由でUbuntu 18.04で作業中
  18. ^ 「ソースコードについて問い合わせました」。2013年9月26日時点のオリジナルよりアーカイブ2013年9月21日閲覧。