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

Re: has K3B been abandoned?

| From: Gene Heskett <gene heskett verizon net>

| [root coyote Fedora-10-i386-DVD]# dd if=/dev/sr0|sha1sum -c SHA1SUM
| Fedora-10-i386-DVD.iso: OK

[Spaces around the pipe symbol would help readability.  Partly because
at least some fonts don't make that glyph very distinct.]

I don't think that that pipeline did what you think that did.

The dd command piped the raw disk contents to sha1sum (as you expect).

The sha1sum command ignored its standard input and checked .iso files
named within the SHA1SUM file (surprise!).

The current working directory had those .iso files.  Try the same
pipeline from within another directory and you will see what I'm
talking about.

So your disk was not checked.

But there is a better way to verify: just do a cmp between the raw
disk and the .iso file.

Why is this better?  Because you can tell cmp how many bytes to read
from the raw disk.  Remember, the raw disk read may appear to have
more bytes than the .iso, and those bytes should be ignored: EOF is
not well defined on a raw disk.  This could also trip up k3b
(speculation on my part).

I use a script called "isoburn" for this stuff.  There are two
relevant features of this script:

- when burning, it pads the file.  Otherwise, on some drives, the
  kernel will generate read errors when a program tries to read near
  the end of the burned part (the kernel does a read-ahead past the
  end and gets upset when the drive gives an error).

- when verifying, it does a cmp with the actual proper length filled
  in.  This uses a feature of GNU cmp not documented in the man page.
  Damn GNU's contempt for man pages.

Here, in essence, is how the verify works (replace file.iso with the
pathname of the .iso file):
	cmp --bytes `isosize file.iso` file.iso /dev/sr0

| So once again all the other excuses, having been removed from the scene, are 
| proven to just excuses, k3b needs fixed.  And it should be using sha1sum too.

I never use k3b's verify anyway.  I'm too impatient to let it complete
the calculation of the hash of the .iso file.  k3b seems to forget
that the hash is wrong (not completely calculated) and thus the
subsequent verification is reported as failing rather than being
impossible to perform.

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