I en automatiseret proces oprettes en iso-fil med mkisofs. Selv da de originale data er nøjagtigt de samme, er de resulterende iso-filer ikke de samme (deres md5sum ændringer). Da jeg rsync --checksum resultatet, kan jeg ikke lide, at den “samme iso” naturligvis overføres hver gang. Jeg forventer for det meste, at tidsstempler er den største forskel.
Er der noget libfaketime buildin switch for at generere en iso via mkisofs det ville faktisk være det samme.
Jeg ved ikke, om kun tidsstempler betyder noget? Jeg har sammenlignet de resulterende iso-filer med deres xxd isofile output som dette:
diff --side-by-side --suppress-common-lines <(xxd a.iso) <(xxd b.iso ) og der synes kun at være 51 linjer, der repræsenterer 16 Bytes (så cirka 800 Bytes forskel) i den ellers nøjagtige samme fil.
Kommandoen, der bruges til at generere denne pågældende iso, er omtrent denne:
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: Mangler jeg en kommandolinjeparameter-switch med rsync, der kontrollerer, at der er ~ 1 MB store stykker for at forhindre overførsel, når som i mit tilfælde er der kun omkring 800 byte forskellige?
Kommentarer
Svar
Først en vigtig note: Brug ikke genisoimage da det er en defekt variant af en mkisofs fra maj 2004.
I tiden frem til maj 2007 er der masser af Debianspecifikke fejl er tilføjet, og siden da er det dødt.
Det vigtige at vide her er, at genisoimage skaber defekte filsystembilleder, der på et tidspunkt muligvis ikke længere accepteres af dit operativsystem …
Den officielle mkisofs er dog stadig aktivt vedligeholdt og fikset masser af ikke-Debian-specifikke fejl i august 2006. Der er i øjeblikket ingen kendte bugs.
Nu til dit problem: Du bruger -R (Rock Rigde), og dette tilføjer UNIX som tidsstempler til filens metadata. Dette er problem nummer 1 ….
Det andet problem er, at ISO-9660-filsystemets superblok (officielt kaldet primær_descriptor) indeholder oprettelsesdatoen og ændringsdatoen. Sidstnævnte kan styres via indstillingen -modification-date.
Hvis du mener, at dette er en virkelig nødvendig funktion, kan jeg tilføje en lignende mulighed for oprettelsesdatoen. Så har du dog stadig brug for en mulighed for at fortælle Rock Ridge-formateringsdelen at bruge ændringsdatoen for filerne i stedet for tidspunktet for den sidste læseadgang.
Ofte opdaterede versioner af den originale kilde er en del af schilytools tarball, der kan hentes fra: http://sourceforge.net/projects/schilytools/files/
Den nyeste schilytools tarball introducerede support til reporducible ISO-9660 filsystembilleder. Hent / kompilér / installer schily-2020-03-27.tar.bz2.
Der er et par nye muligheder:
-
-noatimefortællermkisofsfor at arkivere ændringstiden som et tidspunkt. -
-creation-dateindstiller oprettelsesdatoen i PVD -
-expiration-dateindstiller udløbsdatoen i PVD -
-effective-dateindstiller den effektive dato i PVD -
-reproducible-dateindstiller alle tidspunkter undtagen-effective-dateog-noatimederudover.
Dette fungerer både for vanilje ISO-9660-filsystembilleder og for billeder, der indeholder Rock Ridge og UDF. Se siden for nylig på: http://schilytools.sourceforge.net/man/man8/mkisofs.8.html
Din opdaterede kommandolinje ville se sådan ud :
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-Wfor at tvinge det. Der er etlibfaketimeogfaketimeværktøj til at efterligne systemuret ved hjælp afLD_PRELOAD(hvis ikke setuid).schilytools. Den medfølgende forbedredemkisofsinkluderer understøttelse af reproducerbare tidsstempler. Se det opdaterede svar.