Re: Repeatability of mkisofs?
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: 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). Old versions did not put commandline info in the image. Newer versions (since April 2000) write an anomymized command line and version info. Broken (hacked) versions may behave like old versions. You didn't say anything about atime. If atime changes with every backup, of course they will be different. -- 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]
Re: Repeatability of mkisofs?
Michael Shell [EMAIL PROTECTED] 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? ISO-9660 has 4 timestamps and in the PVC one is the current time 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?
Rob Bogus [EMAIL PROTECTED] wrote: 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). Old versions did not put commandline info in the image. Newer versions (since April 2000) write an anomymized command line and version info. Broken (hacked) versions may behave like old versions. 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?
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]
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]
Repeatability of mkisofs?
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? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
