Parchive (uma palavra-valise de parity archive (arquivo de paridade), e formalmente conhecido como Parity Volume Set Specification) é um sistema de código de apagamento (erasure code) que produz arquivos par para verificação de checksum da integridade de dados, com a capacidade de executar operações de recuperação de dados que podem reparar ou regenerar dados corrompidos ou ausentes. O Parchive foi originalmente escrito para resolver o problema do compartilhamento confiável de arquivos na Usenet, mas pode ser usado para proteger qualquer tipo de dado contra corrupção de dados, deterioração de disco, degradação de dados (bit rot) e danos acidentais ou maliciosos. Apesar do nome, o Parchive usa técnicas mais avançadas (especificamente códigos de correção de erro) do que os métodos simplistas de paridade para a detecção e correção de erros. A partir de 2015, o PAR1 tornou-se obsoleto, o PAR2 está maduro para uso generalizado e o PAR3 é uma versão experimental descontinuada, desenvolvida pelo autor do MultiPar, Yutaka Sawada. O projeto original do Parchive no SourceForge está inativo desde 30 de abril de 2015. Uma nova especificação PAR3 tem sido trabalhada desde 28 de abril de 2019 por Michael Nahas, autor da especificação PAR2. Uma versão alfa da especificação PAR3 foi publicada em 29 de janeiro de 2022, enquanto o próprio programa está sendo desenvolvido.
História O Parchive tinha como objetivo aumentar a confiabilidade da transferência de arquivos via grupos de notícias da Usenet. A Usenet foi originalmente concebida para conversas informais, e o protocolo subjacente, NNTP, não foi projetado para transmitir dados binários arbitrários. Outra limitação, que era aceitável para conversas mas não para arquivos, era que as mensagens eram normalmente curtas e limitadas a texto ASCII de 7 bits. Várias técnicas foram inventadas para enviar arquivos pela Usenet, como uuencoding e Base64. Posteriormente, o software da Usenet passou a permitir ASCII estendido de 8 bits, o que possibilitou novas técnicas como o yEnc. Arquivos grandes eram divididos para reduzir o efeito de um download corrompido, mas a natureza não confiável da Usenet permanecia. Com a introdução do Parchive, arquivos de paridade podiam ser criados e então enviados junto com os arquivos de dados originais. Se algum dos arquivos de dados fosse danificado ou perdido durante a propagação entre os servidores da Usenet, os usuários podiam baixar os arquivos de paridade e usá-los para reconstruir os arquivos danificados ou ausentes. O Parchive incluía a construção de pequenos arquivos de índice (*.par na versão 1 e *.par2 na versão 2) que não contêm nenhum dado de recuperação. Esses índices contêm hashes de arquivos que podem ser usados para identificar rapidamente os arquivos alvo e verificar a sua integridade. Como os arquivos de índice eram muito pequenos, eles minimizavam a quantidade de dados extras que precisavam ser baixados da Usenet para verificar se os arquivos de dados estavam todos presentes e intactos, ou para determinar quantos volumes de paridade eram necessários para reparar qualquer dano ou reconstruir quaisquer arquivos ausentes. Eles foram mais úteis na versão 1, onde os volumes de paridade eram muito maiores que os curtos arquivos de índice. Esses volumes de paridade maiores contêm os dados de recuperação em si, juntamente com uma cópia duplicada das informações nos arquivos de índice (o que permite que eles sejam usados sozinhos para verificar a integridade dos arquivos de dados caso não haja um arquivo de índice pequeno disponível). Em julho de 2001, Tobias Rieper e Stefan Wehlus propuseram a especificação do Parity Volume Set e, com a assistência de outros membros do projeto, a versão 1.0 da especificação foi publicada em outubro de 2001. O Par1 usava a correção de erros Reed-Solomon para criar novos arquivos de recuperação. Qualquer um dos arquivos de recuperação pode ser usado para reconstruir um arquivo ausente a partir de um download incompleto. A versão 1 tornou-se amplamente usada na Usenet, mas sofria de algumas limitações:
Era restrita a lidar com, no máximo, 255 arquivos. Os arquivos de recuperação precisavam ter o tamanho do maior arquivo de entrada, então não funcionava bem quando os arquivos de entrada tinham tamanhos variados. (Isso limitava a sua utilidade quando não estava emparelhado com a ferramenta de compressão proprietária RAR). O algoritmo de recuperação tinha um bug, devido a uma falha no artigo acadêmico no qual se baseava. Estava fortemente atrelado à Usenet e sentia-se que uma ferramenta mais geral poderia ter um público mais amplo. Em janeiro de 2002, Howard Fukada propôs que uma nova especificação Par2 deveria ser desenvolvida com mudanças significativas, de modo que a verificação e o reparo de dados funcionassem em blocos de dados em vez de arquivos inteiros, e que o algoritmo deveria passar a usar números de 16 bits em vez dos números de 8 bits que o PAR1 usava. Michael Nahas e Peter Clements adotaram essas ideias em julho de 2002, com contribuições adicionais de Paul Nettle e Ryan Gallagher (ambos haviam escrito clientes Par1). A versão 2.0 da especificação Parchive foi publicada por Michael Nahas em setembro de 2002. Peter Clements então prosseguiu para escrever as duas primeiras implementações do Par2, o QuickPar e o par2cmdline. Tendo sido abandonado desde 2004, Paul Houle criou o phpar2 para substituir o par2cmdline. Yutaka Sawada criou o MultiPar para substituir o QuickPar. O MultiPar usa o par2j.exe (que é parcialmente baseado nas técnicas de otimização do par2cmdline) como sua engine de backend.
Versões As versões 1 e 2 do formato de arquivo são incompatíveis. (Contudo, muitos clientes suportam ambas.)
Par1 No Par1, para os arquivos f1, f2, ..., fn, o Parchive consiste em um arquivo de índice (f.par), que é um arquivo do tipo CRC sem blocos de recuperação, e um número de "volumes de paridade" (f.p01, f.p02, etc.). Dados todos os arquivos originais exceto um (por exemplo, f2), é possível criar o f2 ausente fornecendo todos os outros arquivos originais e qualquer um dos volumes de paridade. Alternativamente, é possível recriar dois arquivos ausentes a partir de quaisquer dois dos volumes de paridade, e assim por diante. O Par1 suporta até um total de 256 arquivos de origem e recuperação.
Par2 Arquivos Par2 geralmente usam este sistema de nomenclatura/extensão: nomedoarquivo.vol000+01.PAR2, nomedoarquivo.vol001+02.PAR2, nomedoarquivo.vol003+04.PAR2, nomedoarquivo.vol007+06.PAR2, etc. O número após o "+" no nome do arquivo indica quantos blocos ele contém, e o número após "vol" indica o número do primeiro bloco de recuperação dentro do arquivo PAR2. Se um arquivo de índice de um download afirmar que 4 blocos estão faltando, a maneira mais fácil de reparar os arquivos seria baixando nomedoarquivo.vol003+04.PAR2. Contudo, devido à redundância, nomedoarquivo.vol007+06.PAR2 também é aceitável. Existe também um arquivo de índice nomedoarquivo.PAR2, que é idêntico em função ao pequeno arquivo de índice usado no PAR1. A especificação Par2 suporta até 32.768 blocos de origem e até 65.535 blocos de recuperação. Arquivos de entrada são divididos em múltiplos blocos de tamanhos iguais para que os arquivos de recuperação não precisem ter o tamanho do maior arquivo de entrada. Embora o Unicode seja mencionado na especificação PAR2 como uma opção, a maioria das implementações de PAR2 não suporta Unicode. O suporte a diretórios está incluído na especificação PAR2, mas a maioria ou todas as implementações não o suportam.
Par3 A especificação Par3 foi originalmente planejada para ser publicada como um aprimoramento em relação à especificação Par2. No entanto, até à data, o código tem permanecido fechado sob os direitos do proprietário da especificação, Yutaka Sawada. Uma discussão sobre um novo formato começou na seção de problemas (issues) do GitHub do fork mantido do par2cmdline em 29 de janeiro de 2019. A discussão levou a um novo formato, que também foi nomeado Par3. A especificação do novo formato Par3 está publicada no GitHub, mas permanece como um rascunho alfa em 28 de janeiro de 2022. A especificação foi escrita por Michael Nahas, o autor da especificação do Par2, com a ajuda de Yutaka Sawada, animetosho e malaire. O novo formato alega ter múltiplas vantagens em relação ao formato Par2, incluindo suporte para:
Mais de
2
16
{\displaystyle 2^{16}}
arquivos e mais de
2
16
{\displaystyle 2^{16}}
blocos. Empacotamento de pequenos arquivos em um bloco, assim como a deduplicação quando um bloco aparece em múltiplos arquivos. Nomes de arquivos em UTF-8. Permissões de arquivos, links físicos (hard links), links simbólicos/suaves e diretórios vazios. Embutimento de dados PAR dentro de outros formatos, como arquivos ZIP ou imagens de disco ISO. "Backups incrementais", em que um usuário cria arquivos de recuperação para algum arquivo ou pasta, altera alguns dados e cria novos arquivos de recuperação reutilizando alguns dos arquivos mais antigos. Mais algoritmos de código de correção de erros (tais como LDPC e matriz rala aleatória). Hashes BLAKE3, abandonando o suporte aos hashes MD5 usados no PAR2.
Software
Multiplataforma par2+tbb (GPLv2) — uma versão simultânea (multithread) do par2cmdline 0.4 usando TBB. Compatível apenas com CPUs baseadas em arquitetura x86. Está disponível no sistema FreeBSD Ports como par2cmdline-tbb. par2cmdline original — (obsoleto). Disponível no sistema FreeBSD Ports como par2cmdline. par2cmdline fork mantido por BlackIkeEagle. par2cmdline-mt é outra versão multithread do par2cmdline usando OpenMP, sob licença GPLv2 ou posterior. Atualmente unida ao fork de BlackIkeEagle e mantida lá. ParPar (CC0) é um cliente PAR2 multithread de alta performance e biblioteca para Node.js. Não suporta verificação ou reparo, atualmente só pode criar arquivos PAR2. par2deep (LGPL-3.0) — Produz, verifica e repara arquivos par2 recursivamente, tanto na linha de comando quanto com a ajuda de uma interface gráfica do usuário. Está disponível no sistema Python Package Index como par2deep.
Windows MultiPar (freeware) — Constrói sobre os recursos e a GUI do QuickPar, e usa o par2j.exe de Yutaka Sawada como o backend PAR2. O MultiPar suporta múltiplos idiomas por Unicode. O nome do MultiPar originou-se de "cliente PAR multilíngue". Também há relatos verificados de que o MultiPar funciona com o Wine no TrueOS e Ubuntu, e pode funcionar com outros sistemas operacionais também. Embora os componentes do Par2 sejam (ou virão a ser) de código aberto, a interface do MultiPar que atua por cima deles atualmente não é de código aberto. QuickPar (freeware) — sem manutenção desde 2004, substituído pelo MultiPar. phpar2 — par2cmdline avançado com multithreading e código de máquina altamente otimizado (cerca de 66% mais rápido que o QuickPar 0.9.1). Mirror — Primeira implementação de PAR, sem manutenção desde 2001.
Mac OS X MacPAR deLuxe 4.2 UnRarX
POSIX Softwares para sistemas operacionais que aderem ao POSIX:
Par2 para KDE 4 PyPar2 1.4, um frontend para par2. GPar2 2.03
Ver também Comparação de compactadores de arquivos – Alguns compactadores de arquivos são capazes de integrar dados de paridade nos seus formatos para detecção e correção de erros. RAID – Níveis de RAID de 5 em diante fazem uso de dados de paridade para detectar e reparar erros.
Referências
Ligações externas Parity Volume Set Specification 2.0 (2003) Projeto Parchive - especificações completas e a matemática por trás delas Introdução a PAR e PAR2 Guia do Slyck para os Grupos de Notícias da Usenet: Arquivos PAR e PAR2 Arquivado em 2009-10-05 no Wayback Machine Guia para reparar arquivos usando PAR2 Guia do UsenetReviewz sobre como abrir arquivos par
