Re: Repeatability of mkisofs?
Hi, I keep track of the md5sums of all the images I burn. [...] So, I rebuilt a new image via mkisofs from the exact same directory structure used to create the old image. Now, the two images had the exact same byte count, but, much to my surprise, they differed with respect to their md5sums! Why is this? Several possibilities for the differing output files come to mind: 1. mkisofs somehow makes use of a random number generator Rather unnlikely. 2. mkisofs is embedding or using the current time in the output Quite certainly. 3. mkisofs is embedding the output filename/path or the command line as it was invoked within the created image I don't think so. An experiment (at about 8:20 local time) $ mkisofs -l -allow-leading-dots -R -D /u/test | od -c iso1.txt $ mkisofs -l -allow-leading-dots -R -D /u/test | od -c iso2.txt $ diff iso1.txt iso2.txt The diff result is short and in this case it it is typically about a 09 replaced by a 12 on several locations in the images. This seem to be cleartext date+time strings (20060506082009 vs. 20060506082012). The same gesture is done with ASCII 9 and ASCII 12 at two spots which i think are binary representations of the timestamp. 29,30c29,30 0101460 6 0 5 0 6 0 8 2 0 0 9 0 0 \b 2 0 0101500 0 6 0 5 0 6 0 8 2 0 0 9 0 0 \b 0 --- 0101460 6 0 5 0 6 0 8 2 0 1 2 0 0 \b 2 0 0101500 0 6 0 5 0 6 0 8 2 0 1 2 0 0 \b 0 ... 83c83 0114020 8 : 2 0 : 0 9 2 0 0 6 \n m k i --- 0114020 8 : 2 0 : 1 2 2 0 0 6 \n m k i ... 118c118 0160340 005 006 \b 024 \t \b j 001 \n 027 001 0 004 \0 \0 \0 --- 0160340 005 006 \b 024 \f \b j 001 \n 027 001 0 004 \0 \0 \0 I don't think there is an command line option to avoid this. Solution ideas (i would prefer number 1): - one could try to patch the resulting ISO image by identifying the time stamps (of which the value should be easy to guess) and replacing them by the old values. - one could patch mkisofs so that it does use always the same dummy timestamp. There are several calls of time(2) which one would have to examine wether they are to blame for the differences. This will not save you from the real life problem that file system trees on disk change quite easily. Especially with Rock Ridge extensions you are likely to unexpectedly get a different payload of the ISO image. Probably you are better off if you record checksum information about the single files contained in the image. It would be much easier to judge wether a checksum difference is essential or not. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repeatability of mkisofs?
Hi, Michael Shell wrote: 3. mkisofs is embedding the output filename/path or the command line as it was invoked within the created image I wrote: I don't think so. One can be certain and be wrong. 011 M K I S a t M a y 6 1 0110020 0 : 0 1 : 4 9 2 0 0 6 \n m k i 0110040 s o f s 2 . 0 1 . 0 1 a 0 3 0110060 - l - a l l o w - l e a d i n 0110100 g - d o t s - R - D . . . 0110120 / t e s t \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0110140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 So it does record some command line arguments. I am not sure wether the source path gets recorded. At least here is written .../test and not /u/test as used by me. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repeatability of mkisofs?
One can be certain and be wrong. So it does record some command line arguments. One can be both. mkisofs used to record the command line it was invoked with in the iso image, but this was seen as a privacy issue, and changed about 2 years ago. I always record md5sums for each individual file on the CD/DVD itself; this helps a lot to pinpoint any problems to particular files. I also keep checksums of the complete iso image, these are faster to verify and check the whole filesystem, including the metadata and any unused blocks which are nevertheless part of the filesystem. Because the filesystem's creation date is recorded in the iso image, any such image accidentally deleted is non-recoverable and its corresponding checksums worthless. Act wisely :) Of course if such an image was previously burnt, it can be recovered from the burnt disk. I have scripts for all the above tasks. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repeatability of mkisofs?
Volker Kuhlmann [EMAIL PROTECTED] wrote: One can be certain and be wrong. So it does record some command line arguments. One can be both. mkisofs used to record the command line it was invoked with in the iso image, but this was seen as a privacy issue, and changed about 2 years ago. This is not correct: mkisofs records an anonymized variant ot the command line. Some people from Debian who do not even understand their own privacy leak issues (see most if not all patch files found on Debian) _believe_ that there is an issue and apply an unneeded patch. The result of this patch may be that future Solaris releases will not be able to deal with zero sized hard links on ISO-9660 if created wth the bastardized version of mkisofs. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cdrecord-2.0-6.i386.rpm with RedHat 9 and DVDRW
Hi guys, I have an issue trying to burn data into a DVD+RW disc in an IDE BENQ DVD+R/+RW unit connected as master of second ide bus (hdc). All actions are performed as root Here are the details: RedHat 9.0 with 2.4.20-8 stock kernel cdrecord-2.0-6.i386.rpm dvd+rw-tools-5.17.4.8.6-2.i386.rpm **doing SCSI emulation by loading ide-scsi module ** # lsmod Module Size Used byNot tainted autofs 13268 0 (autoclean) (unused) sis900 16812 1 sg 36524 0 (autoclean) ide-scsi 12208 0 (autoclean) sr_mod 18136 0 (autoclean) cdrom 33728 0 (autoclean) [sr_mod] scsi_mod 107160 3 (autoclean) [sg ide-scsi sr_mod] ext3 70784 2 jbd51892 2 [ext3] # DOING BURN AS SCSI DEVICE # cdrecord dev=0,0,0 /root/images/mindi/mindi.iso Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.1.24 Using libscg version 'schily-0.7' cdrecord: Warning: using inofficial libscg transport code version (schily - Red Hat-scsi-linux-sg.c-1.75-RH '@(#)scsi-linux-sg.c1.75 02/10/21 Copyright 1997 J. Schilling'). Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'BENQ' Identifikation : 'DVD DD DW1620 ' Revision : 'B7H9' Device seems to be: Generic mmc2 DVD-R/DVD-RW. cdrecord: Found DVD media but DVD-R/DVD-RW support code is missing. cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support code. cdrecord: If you need DVD-R/DVD-RW support, ask the Author for cdrecord-ProDVD. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96R RAW/R16 RAW/R96R cdrecord: Drive needs to reload the media to return to proper status. Starting to write CD/DVD at speed 31 in real TAO mode for single session. Last chance to quit, starting real write0 seconds. Operation starts. Turning BURN-Free off cdrecord: Input/output error. read track info: scsi sendcmd: no error CDB: 52 01 00 00 00 FF 00 00 1C 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 24 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.002s timeout 240s # # END AS SCSI DEVICE # Scanning the bus as IDE reveals nothing # cdrecord dev=ATAPI -scanbus Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling scsidev: 'ATAPI' devname: 'ATAPI' scsibus: -2 target: -2 lun: -2 Warning: Using ATA Packet interface. Warning: The related libscg interface code is in pre alpha. Warning: There may be fatal problems. cdrecord: No such device or address. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. cdrecord: For possible transport specifiers try 'cdrecord dev=h -- Thanks for your suggestions and pointers to make this DVDRW work. --- Erick Perez Linux User 376588 http://counter.li.org/ (Get counted!!!) Panama, Republic of Panama
Re: cdrecord-2.0-6.i386.rpm with RedHat 9 and DVDRW
Erick Perez [EMAIL PROTECTED] wrote: Hi guys, I have an issue trying to burn data into a DVD+RW disc in an IDE BENQ DVD+R/+RW unit connected as master of second ide bus (hdc). All actions are performed as root Here are the details: RedHat 9.0 with 2.4.20-8 stock kernel cdrecord-2.0-6.i386.rpm you are not using cdrecord but an inofficial hack. If you like to test the real program check ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ or ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repeatability of mkisofs?
Michael Shell wrote: I've got an interesting one. I keep track of the md5sums of all the images I burn. Now, it just so happened that I had deleted an image file that I later needed. So, I rebuilt a new image via mkisofs from the exact same directory structure used to create the old image. Now, the two images had the exact same byte count, but, much to my surprise, they differed with respect to their md5sums! Why is this? Old versions put command line info in the image, creation date is preobably there, and quite likely the atime has changed on parts. I use sumdir to embed md5sums in the directory(s). I used almost the same command line each time: mkisofs -dvd-video -o image.img directory The only difference was in the name/path of the output file. I would expect mkisofs to be deterministic in that the same input data will produce an identical output result (for the same version of mkisofs, in my case this is 2.01). Several possibilities for the differing output files come to mind: 1. mkisofs somehow makes use of a random number generator 2. mkisofs is embedding or using the current time in the output 3. mkisofs is embedding the output filename/path or the command line as it was invoked within the created image It would also be good to know if there is a combination of command line options which will result in identical images with repeated calls to mkisofs (and if not, maybe this would be a good feature to add to mkisofs in the future). Thanks in advance for any info that sheds light on this, Mike Shell -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
AreaLive News: Uscite Discografiche
Almamegretta Almamegretta Presents Dubfellas (Sanacore/RaiTrade) Ecco un nuovo capitolo della saga discografica degli Almamegretta. E un disco che ha nel dub il suo punto focale, trattandosi di brani sostanzialmente strumentali, dove laccento sulla sperimentazione è ancora più marcato rispetto alle passate produzioni. Gli Almamegretta sono uno dei gruppi italiani più originali per la contaminazione musicale, sia a livello di testi che di musica. Il loro sound rappresenta l'incontro ideale della cultura mediterranea con gli stili dub e funky di marchio anglosassone: il risultato è assolutamente innovativo, non solo a livello nazionale. Uscita: a fine maggio in tutte le edicole e in tutti i negozi di dischi a 7,90 euro Bisca Live Set -Il ritorno di Carmela- (Sottattacco/RaiTrade) I brani più noti della band, insieme ad alcuni inediti, registrati in studio con nuovi arrangiamenti ma con gli stessi suoni delle versioni Live. Una presa diretta curata e potente come i loro concerti. Uscita: a inizio giugno in tutte le edicole e in tutti i negozi di dischi a 7,90 euro D.RaD Il Lato D - Tributo a Stefano Facchielli (Sanacore/Edel) Stefano Facchielli, in arte D.RaD, era lanima dub degli Almamegretta e nella sua carriera aveva collaborato con gran parte della scena musicale italiana e internazionale. Grazie alla passione di molti artisti, viene pubblicato il cofanetto Il Lato D., composto di tre cd: - Il primo (Mezzaluna) è una piece di musica elettronica interamente composta da D.RaD (Modulamanopola) nella si quale si ripercorrono le diverse fasi della vita. Un viaggio musicale dal concepimento alla morte. - Nel secondo e il terzo ( D.RaD ), molti artisti (Almamegretta, Raiz, Ligabue, Zampagliene, Coccoluto, Laswell, etc.) della scena nazionale ed internazionale hanno sviluppato le idee musicali che Stefano ha lasciato incompiute, producendo così, per questo progetto/omaggio, ben 26 brani originali. Un progetto importante, segnato dallemozione per una perdita che ha lasciato un vuoto. Uscita: Maggio 2006 -- Se non volete piu' ricevere le nostre comunicazioni inviateci una mail con l'oggetto CANCELLA -- Area Live Viale Colli Aminei 122 80131 - Napoli - Italy Tel. + 39 081 7436271 Fax +39 081 5920933 Cel. +39 335 5384467 [EMAIL PROTECTED] http://www.arealive.it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
