In un processo automatizzato viene creato un file iso con mkisofs. Anche se i dati originali sono esattamente gli stessi, i file ISO risultanti non sono gli stessi (i loro md5sum cambiano). Dato che rsync --checksum il risultato, non mi piace che lo “stesso iso” venga ovviamente ritrasferito ogni volta. Mi aspetto che per lo più i timestamp siano la differenza principale.
Sono presenti alcuni libfaketime switch buildin per generare un ISO tramite mkisofs sarebbe davvero lo stesso.
Non so se contano solo i timestamp? Ho confrontato i file ISO risultanti con il loro output xxd isofile in questo modo:
diff --side-by-side --suppress-common-lines <(xxd a.iso) <(xxd b.iso ) e sembra che ci sia solo 51 righe che rappresentano 16 byte (quindi circa 800 byte di differenza) nellaltro esattamente lo stesso file.
Il comando utilizzato per generare questo ISO in questione è approssimativamente questo:
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: Mi manca un parametro della riga di comando con rsync che esegue il checksum per blocchi di ~ 1 MB di file di grandi dimensioni, in modo da impedire il ritrasferimento quando nel mio caso solo alcuni 800 byte differiscono?
Commenti
Risposta
Prima una nota importante: non utilizzare genisoimage in quanto è una variante difettosa di un mkisofs di maggio 2004.
Nel periodo fino a maggio 2007, molti bug specifici di Debian sono stati aggiunti e da allora è morto.
La cosa importante da sapere qui è che genisoimage crea immagini di filesystem difettose che a un certo punto potrebbero non essere più accettate dal tuo sistema operativo …
Il mkisofs ufficiale è comunque ancora attivamente mantenuto e risolto molti bug specifici non Debian nellagosto 2006. Al momento non sono noti bug.
Ora al tuo problema: stai usando -R (Rock Rigde) e questo aggiunge UNIX come timestamp ai metadati dei file. Questo è il problema numero 1 ….
Laltro problema è che il super blocco del filesystem ISO-9660 (ufficialmente chiamato primary_descriptor) contiene la data di creazione e la data di modifica. Questultimo può essere controllato tramite lopzione -modification-date.
Se ritieni che questa sia una funzionalità davvero necessaria, potrei aggiungere unopzione simile per la data di creazione. Tuttavia, sarebbe comunque necessaria unopzione per indicare alla parte di formattazione di Rock Ridge di utilizzare la data di modifica dei file invece dellora dellultimo accesso in lettura.
Le versioni frequentemente aggiornate della fonte originale fanno parte di il schilytools tarball che può essere recuperato da: http://sourceforge.net/projects/schilytools/files/
Il tarball di schilytools attualmente più recente ha introdotto il supporto per immagini di filesystem ISO-9660 riordinabili. Per favore scarica / compila / installa schily-2020-03-27.tar.bz2.
Ci sono alcune nuove opzioni:
-
-noatimedice amkisofsdi archiviare lora della modifica come atime. -
-creation-dateimposta la data di creazione nel PVD -
-expiration-dateimposta la data di scadenza nel PVD -
-effective-dateimposta la data di validità nel PVD -
-reproducible-dateimposta tutti gli orari tranne-effective-datee-noatimein aggiunta.
Funziona per le immagini del filesystem ISO-9660 vanilla così come per le immagini che contengono Rock Ridge e UDF. Vedi la recente pagina man su: http://schilytools.sourceforge.net/man/man8/mkisofs.8.html
La tua riga di comando aggiornata avrebbe questo aspetto :
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-Wper forzarlo. È disponibile unutilitàlibfaketimeefaketimeper emulare lorologio di sistema utilizzandoLD_PRELOAD(se not setuid).schilytools. Ilmkisofsottimizzato incluso include il supporto per timestamp riproducibili. Vedi la risposta aggiornata.