In een geautomatiseerd proces wordt een ISO-bestand gemaakt met mkisofs. Zelfs als de originele gegevens exact hetzelfde zijn, zijn de resulterende ISO-bestanden niet hetzelfde (hun md5sum wijzigingen). Aangezien ik het resultaat rsync --checksum heb, vind ik het niet prettig dat dezelfde “zelfde iso” natuurlijk elke keer opnieuw wordt overgedragen. Ik verwacht dat vooral tijdstempels het belangrijkste verschil zijn.
Is er een libfaketime ingebouwde switch om een iso te genereren via mkisofs dat zou inderdaad hetzelfde zijn.
Ik weet niet of alleen tijdstempels ertoe doen? Ik heb de resulterende iso-bestanden vergeleken met hun xxd isofile uitvoer als volgt:
diff --side-by-side --suppress-common-lines <(xxd a.iso) <(xxd b.iso ) en er lijken alleen 51 regels die 16 bytes vertegenwoordigen (dus ongeveer 800 bytes verschil) in het andere exact hetzelfde bestand.
Het commando dat wordt gebruikt om deze iso in kwestie te genereren is ongeveer dit:
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: Mis ik een parameer-schakelaar op de opdrachtregel met rsync die controlesom uitvoert voor stukjes grote bestanden van ~ 1MB, om te voorkomen dat in mijn geval verschillen slechts zon 800 bytes?
Opmerkingen
Antwoord
Allereerst een belangrijke opmerking: gebruik aangezien het een defecte variant is van een mkisofs uit mei 2004.
In de tijd tot mei 2007 waren er tal van Debian-specifieke bugs zijn toegevoegd en sindsdien is het dood.
Het belangrijkste om hier te weten is dat genisoimage defecte bestandssysteemafbeeldingen maakt die op een bepaald moment mogelijk niet langer worden geaccepteerd door uw besturingssysteem …
De officiële mkisofs wordt echter nog steeds actief onderhouden en heeft in augustus 2006 een groot aantal niet-Debian-specifieke bugs verholpen. Er zijn momenteel geen bekende bugs.
Nu het probleem: je gebruikt -R (Rock Rigde) en dit voegt UNIX als tijdstempels toe aan de metagegevens van de bestanden. Dit is probleem nummer 1 …
Het andere probleem is dat het superblok van het ISO-9660 bestandssysteem (officieel primaire_descriptor genoemd) de aanmaakdatum en de wijzigingsdatum bevat. Dit laatste kan worden bediend via de optie -modification-date.
Als je denkt dat dit een echt noodzakelijke functie is, zou ik een vergelijkbare optie kunnen toevoegen voor de aanmaakdatum. Dan heb je echter nog steeds een optie nodig om het opmaakgedeelte van Rock Ridge te vertellen de wijzigingsdatum van de bestanden te gebruiken in plaats van de tijd van de laatste leestoegang.
Regelmatig bijgewerkte versies van de originele bron maken deel uit van de schilytools tarball die kan worden opgehaald uit: http://sourceforge.net/projects/schilytools/files/
De momenteel nieuwste tarball van schilytools introduceerde ondersteuning voor herleidbare ISO-9660 bestandssysteemafbeeldingen. Haal / compileer / installeer schily-2020-03-27.tar.bz2.
Er zijn een paar nieuwe opties:
-
-noatimeverteltmkisofsom de wijzigingstijd als een tijd te archiveren. -
-creation-datestelt de aanmaakdatum in de PVD in -
-expiration-datestelt de vervaldatum in de PVD in -
-effective-datestelt de ingangsdatum in de PVD in -
-reproducible-datestelt alle tijden in behalve-effective-dateen-noatimebovendien.
Dit werkt zowel voor vanille ISO-9660 bestandssysteemafbeeldingen als voor afbeeldingen die Rock Ridge en . Zie de recente man-pagina op: http://schilytools.sourceforge.net/man/man8/mkisofs.8.html
Uw bijgewerkte opdrachtregel zou er zo uitzien :
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-Wtoe om het te forceren. Er is eenlibfaketimeenfaketimehulpprogramma om de systeemklok te emuleren metLD_PRELOAD(indien niet setuid).schilytoolsgepubliceerd. De meegeleverde verbeterdemkisofsbevat ondersteuning voor reproduceerbare tijdstempels. Zie het bijgewerkte antwoord.