Em um processo automatizado, um arquivo iso é criado com mkisofs. Mesmo que os dados originais sejam exatamente os mesmos, os arquivos iso resultantes não são os mesmos (suas md5sum alterações). Como eu rsync --checksum o resultado, não gosto que a “mesma iso” seja retransferida sempre. Espero que os timestamps sejam a principal diferença.
Existe algum libfaketime switch de build para gerar uma iso por meio de mkisofs isso seria realmente o mesmo.
Não sei se apenas os carimbos de data / hora são importantes. Eu comparei os arquivos iso resultantes com seus xxd isofile resultados como este:
diff --side-by-side --suppress-common-lines <(xxd a.iso) <(xxd b.iso ) e parece haver apenas 51 linhas representando 16 bytes (cerca de 800 bytes de diferença) no mesmo arquivo.
O comando usado para gerar esta iso em questão é aproximadamente este:
genisoimage -o "file.iso" -b isolinux/isolinux.bin \ -c isolinux/boot.cat -no-emul-boot \ -boot-load-size 4 -boot-info-table \ -J -R -v -T -V "CDLABEL" "datadir/" BS: Estou faltando uma chave de parâmetro de linha de comando com rsync que faz a soma de verificação para pedaços de aproximadamente 1 MB de arquivos grandes, para evitar a retransferência quando no meu caso, apenas 800 bytes diferem?
Comentários
Resposta
Primeiro, uma observação importante: não use genisoimage visto que é uma variante defeituosa de um mkisofs de maio de 2004.
Até maio de 2007, muitos bugs específicos do Debian foram adicionados e, desde então, está morto.
O importante saber aqui é que genisoimage cria imagens do sistema de arquivos com defeito que em algum momento podem não ser mais aceitas pelo seu sistema operacional …
O mkisofs oficial, no entanto, ainda é mantido ativamente e corrigido muitos bugs não específicos do Debian em agosto de 2006. Atualmente não há nenhum conhecido bugs.
Agora, para o seu problema: você está usando -R (Rock Rigde) e isso adiciona UNIX como timestamps aos metadados dos arquivos. Este é o problema número 1 ….
O outro problema é que o super bloco do sistema de arquivos ISO-9660 (oficialmente chamado primary_descriptor) contém a data de criação e a data de modificação. O último pode ser controlado por meio da opção -modification-date.
Se você acredita que esse é um recurso realmente necessário, eu poderia adicionar uma opção semelhante para a data de criação. No entanto, você ainda precisaria de uma opção para informar a parte de formatação de Rock Ridge para usar a data de modificação dos arquivos em vez da hora do último acesso de leitura.
Versões frequentemente atualizadas da fonte original fazem parte de o schilytools tarball que pode ser recuperado em: http://sourceforge.net/projects/schilytools/files/
O tarball do schilytools mais recente introduziu suporte para imagens de sistema de arquivos ISO-9660 repordutíveis. Obtenha / compile / instale schily-2020-03-27.tar.bz2.
Existem algumas novas opções:
-
-noatimediz amkisofspara arquivar a hora da modificação como atime. -
-creation-datedefine a data de criação no PVD -
-expiration-datedefine a data de expiração no PVD -
-effective-datedefine a data efetiva no PVD -
-reproducible-datedefine todos os tempos, exceto-effective-datee-noatimealém disso.
Isso funciona para imagens do sistema de arquivos ISO-9660 vanilla, bem como para imagens que contêm Rock Ridge e UDF. Veja a página de manual recente em: http://schilytools.sourceforge.net/man/man8/mkisofs.8.html
Sua linha de comando atualizada teria esta aparência :
mkisofs -b isolinux/isolinux.bin \ -c isolinux/boot.cat -no-emul-boot \ -boot-load-size 4 -boot-info-table \ -J -R -v -T -V "CDLABEL" \ -reproducible-date=20200327 "datadir/" > file.iso
--no-Wpara forçá-lo. Há um utilitáriolibfaketimeefaketimepara emular o relógio do sistema usandoLD_PRELOAD(se não setuid).schilytools. Omkisofsaprimorado incluído inclui suporte para carimbos de data / hora reproduzíveis. Veja a resposta atualizada.