Re: Repeatability of mkisofs?

[scdbackup@gmx.net]

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