I en automatiserad process skapas en isofil med mkisofs. Även eftersom originaldata är exakt desamma är de resulterande isofilerna inte desamma (deras md5sum ändras). Eftersom jag rsync --checksum resultatet, ogillar jag att ”samma iso” naturligtvis överförs varje gång. Jag förväntar mig att mestadels tidsstämplar är den största skillnaden.

Finns det någon libfaketime build-switch för att generera en iso via mkisofs det skulle verkligen vara detsamma.

Jag vet inte om bara tidsstämplar spelar roll? Jag har jämfört de resulterande isofilerna med deras xxd isofile -utdata så här: 

diff --side-by-side --suppress-common-lines <(xxd a.iso) <(xxd b.iso )

och det verkar bara finnas 51 rader som representerar 16 byte (så ungefär 800 byte av skillnad) i den andra exakt samma filen.

Kommandot som används för att generera denna iso i fråga är ungefär detta: ”>

BS: Saknar jag en kommandoradsparametraromkopplare med rsync som gör kontrollsummning för ~ 1 MB bitar av stora filer för att förhindra återöverföring när som i mitt fall är det bara cirka 800 byte som skiljer sig åt?

Kommentarer

  • rsync kontrollerar vanligtvis delar av filer för att optimera uppdateringar, men inte om de båda är uppenbarligen lokala (t.ex. på nfs). Lägg till --no-W för att tvinga det. Det finns ett libfaketime och faketime verktyg för att emulera systemklockan med LD_PRELOAD inte setuid).
  • Hej, jag har precis publicerat en ny version av schilytools. Den inkluderade förbättrade mkisofs innehåller stöd för reproducerbara tidsstämplar. Se det uppdaterade svaret.

Svar

Först en viktig anmärkning: Använd inte genisoimage eftersom det är en defekt variant av en mkisofs från maj 2004.

Under tiden fram till maj 2007, många Debianspecifika buggar har lagts till och sedan dess är den död.

Det viktiga att veta här är att genisoimage skapar defekta filsystembilder som någon gång kanske inte längre accepteras av ditt operativsystem …

Den officiella mkisofs underhålls dock fortfarande aktivt och fixade många fel som inte är Debian-specifika i augusti 2006. Det finns för närvarande inga kända buggar.

Nu till ditt problem: Du använder -R (Rock Rigde) och detta lägger till UNIX som tidsstämplar till filens metadata. Detta är problem nummer 1 ….

Det andra problemet är att ISO-9660-filsystemets superblock (officiellt kallat primär_descriptor) innehåller skapandedatum och modifieringsdatum. Det senare kan styras via alternativet -modification-date.

Om du tror att det här är en verkligen nödvändig funktion kan jag lägga till ett liknande alternativ för skapelsedatumet. Då skulle du dock fortfarande behöva ett alternativ för att berätta för Rock Ridge-formateringsdelen att använda ändringsdatumet för filerna istället för tiden för den senaste läsbehörigheten.

Ofta uppdaterade versioner av den ursprungliga källan ingår i schilytools tarball som kan hämtas från: http://sourceforge.net/projects/schilytools/files/

Den senaste schilytools tarball introducerade stöd för reporducible ISO-9660 filsystembilder. Hämta / kompilera / installera schily-2020-03-27.tar.bz2.

Det finns några nya alternativ:

  • -noatime säger till mkisofs att arkivera ändringstiden när som helst.

  • -creation-date ställer in skapande datum i PVD

  • -expiration-date ställer in utgångsdatum i PVD

  • -effective-date anger effektdatum i PVD

  • -reproducible-date ställer in alla tider utom för -effective-date och -noatime.

Detta fungerar för vanilj ISO-9660-filsystembilder liksom för bilder som innehåller Rock Ridge och UDF. Se den senaste mansidan på: http://schilytools.sourceforge.net/man/man8/mkisofs.8.html

Din uppdaterade kommandorad skulle se ut så här : 

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

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *