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

Re: growisofs should have a method for padding



| From: Patrick Ohly <Patrick.Ohly@gmx.de>
| Date: Tue, 24 May 2005 22:16:34 +0200

| On Thu, 2005-05-12 at 01:26 -0400, D. Hugh Redelmeier wrote:
| > The conventional work-around is to always pad when writing a CD/DVD.
| > Ugly, but true.  (I agree that this isn't the correct fix, but the
| > problem has not been fixed in a year, so it isn't going away soon.)
| 
| As a matter of fact, for CDs it is exactly the right solution. As
| discussed on this list in April 2000 under the subject "Reading out
| data CDs" (not sure whether any public archive has those emails),
| the Yellow Book standard for data CDs requires data tracks to end
| in 150 empty blocks (300KB).

That thread seems to be:
http://groups.google.ca/group/mailing.comp.cdwrite/browse_frm/thread/ab41402747ff62af/568f34f142e706bd?tvc=1&q=%22reading+out+data+cds%22&hl=en#568f34f142e706bd
Your message (number 10) seems relevant, but the padding is expressed
in seconds, so I'm not 100% convinced that it applies to data.

I tested Fedora Core 4 binary .iso files and found that each ended in
601 or 602 blocks of 512 zeros.  This seems consistent with what you
say.

| Therefore a CD writing file system is allowed to read ahead up to
| 150 blocks after the end of the last block with real data
| and should not run into read errors there. How it should handle
| read errors is a different question, but it doesn't change the fact
| that it only occurs with broken CDs or when reading valid CDs
| beyond the end of the last block with user data.

It also happens when software tries to find the whole (raw) content of
the .iso file on the raw cdrom.  When does this happen?

- when trying to duplicate a CD

- when trying to compare a CD with a .iso

- When trying to compute a cryptographic hash of the contents of a CD.
  k3b seems to do this.  So do various check-before-installing codes.

So it still seems wise to add padding beyond the length of the .iso
file.

Here is my quicky script to count the blank blocks at the end of a
.iso file.  I realize that the zeros ought to be in sectors of 2048
bytes, but checking in units of 512 seemed a little more informative.

================ isozeros script ================
# isozeros: test for zero blocks at end of .iso

set -e -u

bs=512

for fn
do
	sz=`isosize "$fn"`
	szb=`expr $sz / $bs`
	i=$szb
	while [ $i -ge 1 ]
	do
		i=`expr $i - 1`
		if ! dd if="$fn" skip=$i bs=$bs count=1 2>/dev/null | cmp --bytes $bs - /dev/zero
		then
			i=`expr $i + 1`
			break
		fi
	done
	echo "$fn has `expr $szb - $i` blocks of $bs bytes of zeros at the end"
done
================ end ================



Reply to: