En un proceso automatizado, se crea un archivo iso con mkisofs. Incluso, dado que los datos originales son exactamente los mismos, los archivos iso resultantes no son los mismos (sus md5sum cambios). Dado que rsync --checksum el resultado, no me gusta que la «misma iso» sea, por supuesto, retransferida cada vez. Espero que la principal diferencia sean las marcas de tiempo.
¿Existe algún libfaketime buildin switch para generar una iso a través de mkisofs eso sería lo mismo.
No sé si solo importan las marcas de tiempo. He comparado los archivos iso resultantes con su xxd isofile salida como esta:
diff --side-by-side --suppress-common-lines <(xxd a.iso) <(xxd b.iso ) y parece que solo hay 51 líneas que representan 16 bytes (es decir, aproximadamente 800 bytes de diferencia) en el mismo archivo.
El comando utilizado para generar este iso en cuestión es 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: ¿Me falta un parámetro de parámetro de línea de comando con rsync que realiza la suma de comprobación para fragmentos de ~ 1 MB de archivos grandes, para evitar la retransferencia cuando en mi caso solo difieren unos 800 bytes?
Comentarios
Respuesta
Primero, una nota importante: no utilice genisoimage ya que es una variante defectuosa de una mkisofs de mayo de 2004.
Hasta mayo de 2007, muchos errores específicos de Debian se han agregado y desde entonces está muerto.
Lo importante que debe saber aquí es que genisoimage crea imágenes defectuosas del sistema de archivos que en algún momento ya no serán aceptadas por su sistema operativo …
Sin embargo, el mkisofs oficial todavía se mantiene activamente y se corrigieron muchos errores no específicos de Debian en agosto de 2006. Actualmente no se conocen bugs.
Ahora a su problema: está usando -R (Rock Rigde) y esto agrega UNIX como marcas de tiempo a los metadatos de los archivos. Este es el problema número 1 ….
El otro problema es que el superbloque del sistema de archivos ISO-9660 (oficialmente llamado primary_descriptor) contiene la fecha de creación y la fecha de modificación. Este último se puede controlar mediante la opción -modification-date.
Si cree que esta es una característica realmente necesaria, podría agregar una opción similar para la fecha de creación. Entonces, sin embargo, todavía necesitaría una opción para decirle a la parte de formato de Rock Ridge que use la fecha de modificación de los archivos en lugar de la hora del último acceso de lectura.
Las versiones actualizadas con frecuencia de la fuente original son parte de el schilytools tarball que se puede recuperar de: http://sourceforge.net/projects/schilytools/files/
El tarball de schilytools más reciente introdujo soporte para imágenes repetibles del sistema de archivos ISO-9660. Busque / compile / instale schily-2020-03-27.tar.bz2.
Hay algunas opciones nuevas:
-
-noatimele dice amkisofsque archive la hora de modificación como atime. -
-creation-dateestablece la fecha de creación en el PVD -
-expiration-dateestablece la fecha de vencimiento en el PVD -
-effective-dateestablece la fecha de vigencia en el PVD -
-reproducible-dateestablece todos los tiempos excepto-effective-datey-noatimeademás.
Esto funciona para imágenes del sistema de archivos estándar ISO-9660, así como para imágenes que contienen Rock Ridge y UDF. Consulte la página de manual reciente en: http://schilytools.sourceforge.net/man/man8/mkisofs.8.html
Su línea de comando actualizada se vería de esta manera :
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 forzarlo. Existe una utilidadlibfaketimeyfaketimepara emular el reloj del sistema medianteLD_PRELOAD(si not setuid).schilytools. Elmkisofsmejorado incluido incluye compatibilidad con marcas de tiempo reproducibles. Consulte la respuesta actualizada.