Archives

Parchive (un mot-valise de parity archive , et officiellement connu sous le nom de Parity Volume Set Specification ) est un système de code d'effacement qui produit des fichiers par pour la vérification de la somme de contrôle de l'intégrité des données , avec la capacité d'effectuer des opérations de récupération de données qui peuvent réparer ou régénérer des données corrompues ou manquantes.

Parchive a été écrit à l'origine pour résoudre le problème du partage fiable de fichiers sur Usenet , mais il peut être utilisé pour protéger tout type de données contre la corruption des données , la pourriture du disque , la pourriture des bits et les dommages accidentels ou malveillants. Malgré son nom, Parchive utilise des techniques plus avancées (en particulier des codes de correction d'erreur ) que des méthodes de parité simplistes de détection d'erreurs .

En 2014, PAR1 est obsolète, PAR2 est mature pour une utilisation généralisée et PAR3 est une version expérimentale abandonnée développée par l'auteur de MultiPar, Yutaka Sawada. Le projet SourceForge Parchive original est inactif depuis le 30 avril 2015. Une nouvelle spécification PAR3 est en cours d'élaboration depuis le 28 avril 2019 par l'auteur de la spécification PAR2, Michael Nahas. Une version alpha de la spécification PAR3 a été publiée le 29 janvier 2022 pendant que le programme lui-même est en cours de développement.

Parchive a été conçu pour augmenter la fiabilité du transfert de fichiers via les groupes de discussion Usenet . Usenet a été conçu à l'origine pour les conversations informelles et le protocole sous-jacent, NNTP , n'a pas été conçu pour transmettre des données binaires arbitraires. Une autre limitation, qui était acceptable pour les conversations mais pas pour les fichiers, était que les messages étaient normalement assez courts et limités à du texte ASCII 7 bits .

Différentes techniques ont été conçues pour envoyer des fichiers via Usenet, comme uuencoding et Base64 . Les logiciels Usenet ultérieurs ont permis l'utilisation du format ASCII étendu 8 bits , qui a permis l'utilisation de nouvelles techniques comme yEnc . Les fichiers volumineux ont été fractionnés pour réduire l'effet d'un téléchargement corrompu, mais la nature peu fiable d'Usenet est restée.

Avec l'introduction de Parchive, des fichiers de parité ont pu être créés et téléchargés avec les fichiers de données d'origine. Si l'un des fichiers de données était endommagé ou perdu lors de sa propagation entre les serveurs Usenet, les utilisateurs pouvaient télécharger des fichiers de parité et les utiliser pour reconstruire les fichiers endommagés ou manquants. Parchive comprenait la construction de petits fichiers d'index (*.par dans la version 1 et *.par2 dans la version 2) qui ne contiennent aucune donnée de récupération. Ces index contiennent des hachages de fichiers qui peuvent être utilisés pour identifier rapidement les fichiers cibles et vérifier leur intégrité.

Les fichiers d'index étant très petits, ils réduisaient la quantité de données supplémentaires à télécharger depuis Usenet pour vérifier que les fichiers de données étaient tous présents et non endommagés, ou pour déterminer le nombre de volumes de parité nécessaires pour réparer les dommages ou reconstruire les fichiers manquants. Ils étaient particulièrement utiles dans la version 1, où les volumes de parité étaient beaucoup plus volumineux que les fichiers d'index courts. Ces volumes de parité plus volumineux contiennent les données de récupération réelles ainsi qu'une copie dupliquée des informations contenues dans les fichiers d'index (ce qui permet de les utiliser seuls pour vérifier l'intégrité des fichiers de données s'il n'y a pas de petit fichier d'index disponible).

En juillet 2001, Tobias Rieper et Stefan Wehlus ont proposé la spécification Parity Volume Set et, avec l'aide d'autres membres du projet, la version 1.0 de la spécification a été publiée en octobre 2001. Par1 a utilisé la correction d'erreur Reed-Solomon pour créer de nouveaux fichiers de récupération. N'importe lequel des fichiers de récupération peut être utilisé pour reconstruire un fichier manquant à partir d'un téléchargement incomplet .

La version 1 est devenue largement utilisée sur Usenet, mais elle souffrait de certaines limitations :

• Il a été limité à 255 fichiers au maximum.
• Les fichiers de récupération devaient avoir la taille du plus grand fichier d'entrée, ce qui ne fonctionnait pas bien lorsque les fichiers d'entrée étaient de tailles différentes. (Cela limitait son utilité lorsqu'il n'était pas associé à l'outil de compression RAR propriétaire.)
• L'algorithme de récupération présentait un bug, dû à une faille dans l'article académique sur lequel il était basé.
• Il était fortement lié à Usenet et on pensait qu’un outil plus général pourrait avoir un public plus large.

En janvier 2002, Howard Fukada a proposé qu'une nouvelle spécification Par2 soit élaborée avec des changements importants : la vérification et la réparation des données devraient fonctionner sur des blocs de données plutôt que sur des fichiers entiers, et que l'algorithme devrait passer à l'utilisation de nombres à 16 bits plutôt qu'aux nombres à 8 bits utilisés par PAR1. Michael Nahas et Peter Clements ont repris ces idées en juillet 2002, avec des contributions supplémentaires de Paul Nettle et Ryan Gallagher (qui ont tous deux écrit des clients Par1). La version 2.0 de la spécification Parchive a été publiée par Michael Nahas en septembre 2002.

Peter Clements a ensuite écrit les deux premières implémentations de Par2, QuickPar et par2cmdline. Abandonné depuis 2004, Paul Houle a créé phpar2 pour remplacer par2cmdline. Yutaka Sawada a créé MultiPar pour remplacer QuickPar. MultiPar utilise par2j.exe (qui est partiellement basé sur les techniques d'optimisation de par2cmdline) comme moteur backend de MultiPar.

Les versions 1 et 2 du format de fichier sont incompatibles. (Cependant, de nombreux clients prennent en charge les deux.)

Pour Par1, les fichiers f1 , f2 , ..., fn , la Parchive se compose d'un fichier d'index ( f.par ), qui est un fichier de type CRC sans blocs de récupération, et d'un certain nombre de « volumes de parité » ( f.p01 , f.p02 , etc.). Étant donné tous les fichiers d'origine à l'exception d'un (par exemple, f2 ), il est possible de créer le f2 manquant étant donné tous les autres fichiers d'origine et l'un des volumes de parité. Alternativement, il est possible de recréer deux fichiers manquants à partir de deux volumes de parité quelconques et ainsi de suite.

Par1 prend en charge jusqu'à un total de 256 fichiers sources et de récupération.

Les fichiers Par2 utilisent généralement ce système de dénomination/extension : filename.vol000+01.PAR2 , filename.vol001+02.PAR2 , filename.vol003+04.PAR2 , filename.vol007+06.PAR2 , etc. Le nombre après le « + » dans le nom de fichier indique le nombre de blocs qu'il contient, et le nombre après « vol » indique le numéro du premier bloc de récupération dans le fichier PAR2. Si un fichier d'index d'un téléchargement indique que 4 blocs manquent, le moyen le plus simple de réparer les fichiers serait de télécharger filename.vol003+04.PAR2 . Cependant, en raison de la redondance, filename.vol007+06.PAR2 est également acceptable. Il existe également un fichier d'index filename.PAR2 , dont la fonction est identique au petit fichier d'index utilisé dans PAR1.

La spécification Par2 prend en charge jusqu'à 32 768 blocs sources et jusqu'à 65 535 blocs de récupération. Les fichiers d'entrée sont divisés en plusieurs blocs de taille égale afin que les fichiers de récupération n'aient pas besoin d'avoir la taille du plus grand fichier d'entrée.

Bien que Unicode soit mentionné dans la spécification PAR2 comme une option, la plupart des implémentations PAR2 ne prennent pas en charge Unicode.

La prise en charge des répertoires est incluse dans la spécification PAR2, mais la plupart ou toutes les implémentations ne la prennent pas en charge.

La spécification Par3 devait initialement être publiée comme une amélioration de la spécification Par2. Cependant, à ce jour, elle est restée fermée par le propriétaire de la spécification, Yutaka Sawada.

Une discussion sur un nouveau format a débuté dans la section des problèmes GitHub du fork maintenu par2cmdline le 29 janvier 2019. La discussion a conduit à un nouveau format qui est également nommé Par3. La spécification du nouveau format Par3 est publiée sur GitHub, mais reste à l'état de brouillon alpha au 28 janvier 2022. La spécification est écrite par Michael Nahas, l'auteur de la spécification Par2, avec l'aide de Yutaka Sawada, animetosho et malaire.

Le nouveau format prétend avoir de multiples avantages par rapport au format Par2, notamment :

• Prend en charge plus de 2 ¹⁶ fichiers et plus de 2 ¹⁶ blocs.
• Prend en charge le regroupement de petits fichiers dans un seul bloc, ainsi que la déduplication lorsqu'un bloc apparaît dans plusieurs fichiers.
• Prend en charge les noms de fichiers UTF-8 , les autorisations de fichiers, les liens physiques et les liens symboliques.
• Prend en charge l'intégration de données PAR dans d'autres formats, tels que des archives ZIP ou des images de disque ISO.
• Prend en charge les « sauvegardes incrémentielles », où un utilisateur crée des fichiers de récupération pour un fichier ou un dossier, modifie certaines données et crée de nouveaux fichiers de récupération en réutilisant certains des fichiers plus anciens.
• Prend en charge davantage d'algorithmes de code de correction d'erreur (tels que LDPC et matrice aléatoire clairsemée).
• Remplacement de la fonction de hachage MD5 dans Par2 par BLAKE3 .
• Prend en charge les répertoires vides.
• Prend en charge les autorisations de fichiers.
• Prend en charge les liens physiques et les liens symboliques.

• par2+tbb ( GPLv2 ) — une version concurrente (multithread) de par2cmdline 0.4 utilisant TBB . Compatible uniquement avec les processeurs x86 . Il est disponible dans le système de ports FreeBSD sous le nom par2cmdline-tbb.
• par2cmdline d'origine — (obsolète). Disponible dans le système de ports FreeBSD sous le nom par2cmdline.
• par2cmdline a maintenu un fork par BlackIkeEagle.
• par2cmdline-mt est une autre version multithread de par2cmdline utilisant OpenMP , GPLv2 ou une version ultérieure. Actuellement intégré dans le fork de BlackIkeEagle et maintenu là-bas.
• ParPar ( CC0 ) est un client PAR2 multithread hautes performances et une bibliothèque Node.js. Il ne prend pas en charge la vérification ou la réparation, il ne peut actuellement créer que des archives PAR2.
• par2deep ( LGPL-3.0 ) — Produisez, vérifiez et réparez les fichiers par2 de manière récursive, à la fois sur la ligne de commande et à l'aide d'une interface utilisateur graphique. Il est disponible dans le système d'index des packages Python sous le nom de par2deep.

• MultiPar (logiciel gratuit) — S'appuie sur les fonctionnalités et l'interface graphique de QuickPar et utilise par2j.exe de Yutaka Sawada comme backend PAR2. MultiPar prend en charge plusieurs langues par Unicode. Le nom de MultiPar est dérivé de « client PAR multilingue ». MultiPar est également vérifié pour fonctionner avec Wine sous TrueOS et Ubuntu et peut également fonctionner avec d'autres systèmes d'exploitation. Bien que les composants Par2 soient (ou seront) open source, l'interface graphique MultiPar qui les surmonte n'est pas actuellement open source.
• QuickPar (gratuit) — non maintenu depuis 2004, remplacé par MultiPar.
• phpar2 — par2cmdline avancé avec multithreading et code assembleur hautement optimisé (environ 66 % plus rapide que QuickPar 0.9.1)
• Miroir — Première implémentation PAR, non maintenue depuis 2001.

• MacPAR deLuxe 4.2
• UnRarX

Logiciel pour systèmes d'exploitation conformes POSIX :

• Par2 pour KDE 4
• PyPar2 1.4, une interface pour par2.
• GPar2 2.03