Estou tentando determinar se há algum problema potencial usando bzip2para compactar arquivos que precisam ser 100% reproduzíveis. Especificamente: os metadados (nome/inode, data do último mod, etc) ou qualquer outra coisa podem fazer com que conteúdos de arquivos idênticos produzam uma soma de verificação diferente no arquivo resultante .bz2?
Como exemplo, gzip não é determinístico por padrão , a menos que -nseja usado.
Meus testes brutos até agora sugerem que o bzip2 de fato produz consistentemente arquivos idênticos com dados de entrada idênticos (independentemente de metadados, plataforma, sistema de arquivos etc.), mas seria bom ter mais do que evidências anedóticas.
bzip2os arquivos contêm apenas assinaturas de formato básico, dados compactados e as informações necessárias para descompactar esses dados . Eles não contêm metadados específicos de arquivo; em vez disso, eles dependem dos metadados do arquivo compactado (portanto,file.bz2é descompactado parafile, com os carimbos de data/hora defile.bz2, independentemente do nome do arquivo original e dos carimbos de data/hora originais).Há uma parte da compressão que pode variar, a randomização de entrada; mas isso está desabilitado na prática há muito tempo, e as versões atuais
bzip2não aleatorizam sua entrada.Como resultado, a saída de
bzip2depende apenas dos dados de entrada e do nível de compactação. A saída é determinística.Não tenho certeza se você encontrará uma fonte confiável para tudo isso; a melhor evidência que posso oferecer é a ausência de qualquer menção
bzip2nas notas de compilação reproduzíveis do Debian .bzip2é usado no Debian, portanto, se causasse problemas, seria mencionado, da mesma formagzipque o .