[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dvd md5sum connundrum

On Sunday 20 November 2005 16:09, scdbackup@gmx.net wrote:
>> >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 :)

Do you wish to share these scripts?  And how would I go about
incorporating them into the k3b invocation?

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Reply to: