dvd md5sum connundrum

[scdbackup@gmx.net]

Hi,

> >Another approach would be to add some recognizable bytes as
> >an end mark to the payload data when writing to media.
> 
> And that would no doubt require growisofs to be modified in some way to
> achive this.

A classical shell pipe is sufficient :

   tag_adder <image.iso | growisofs ... -Z /dev/cdrom=/proc/self/fd/0

The tag_adder reads the payload data up to the end and then adds
its own information to the stream.

I employ a pipeline like  
   formatter | checksummer | writer
with formatter={mkisofs,afio,star} and writer={cdrecord,growisofs,...}
The checksummer computes a MD5 and adds a recognizable checksum tag
to the formatter's output. 
The writer then may append what it wants. The eventual reader may
also append what it wants. Usually both do ... or at least may do.


>  what we need is the ability to get, from the dvd, the size of
> the image.  That doesn't appear to be available, or is this something
> that is there, but just not read by the *info utils?

In my eyes it is obscure science to guess the former size of mkisofs'
output from the current state of a DVD-like media.
I don't outrule that it is possible. But will it be stable ?


> I have problems
> with depending on the availability of the original .iso image for this.

You don't have to keep the whole image.
Keep its size and its MD5. 

I use a printable text record like

  1_2 A51120.182320 4340664320 c65c415fed6f1b1c3e1b3454a6dc5f1f

saying it's volume 1 of 2, written today, 4340664320 bytes, MD5.
All you need to verify this is a cutter program and md5sum :

  dd bs=1 count=4340664320 if=/dev/cdrom | md5sum

(dd bs=1 has a darn poor performance, of course. Better is 
  dd bs=2048 count=2119465 if=/dev/cdrom | md5sum
)


For recognizing an appended end mark one may use a
recognizer filter. Like

  recognizer_filter </dev/cdrom | md5sum

It has to watch the incomming data stream for the end mark,
forward the payload data and close stdout rather than to
output the end mark's bytes.

My own recognizer computes the MD5 on its own and compares
it against the MD5 which it read from the end mark. So it does
not have to rely on the checksum records on hard disk.


Have a nice day :)

Thomas