On 2011-05-01 04:06, ken yap wrote:
>
> That’s what I meant by if you accept that EOF on $1 is harmless. BTW
> it’s not the burner that pads the burn, it’s the software. The image is
> already padded so that precaution is unnecessary, but harmless.
That’s the theory, but not the fact. As I said, we had to made that code up
because the images we had did not pass a plain cmp test. The line of code
was not designed for pleasure, but because we had a problem.
You can dig out the thread in the mail list where we discussed the matter
and the explanations were found. I had images that did not compare to the
dvd, I asked, and got answers. The why it happened and how to solve it.
If you look up in the manuals, you will see that the padding is optional,
at least with some CLUs.
> You probably got an instantaneous response from the wc because you had
> the blocks cached in RAM.
Most certainly not. Thats the ~4 GiB iso of the distribution, and I haven’t
used it in two weeks. Look, I’ll repeat the test with another file I
haven’t used in months:
cer@Telcontar:~> time wc -c < /data/storage_a/imgs/crypta_f1_dvd.mm.xfs
4700012544
real 0m0.019s
user 0m0.000s
sys 0m0.002s
By the way: the image above is for a DVD, but not ISO.
Another one, 11GB in size:
cer@Telcontar:~> time wc -c < /data/storage_b/copias_vmware/OpenSuSE
11.1/OpenSuSE\ 11.1-flat.vmdk
11274289152
real 0m0.002s
user 0m0.001s
sys 0m0.000s
Try it yourself.
> And if you really want to be more thorough with the checking you should
> only compare as many 2048 byte blocks as the ISO image specifies. That
> will also catch some $1 errors. But in this case $1 is known to be good.
$1 is the image file, and its exact size determines the comparison. It
doesn’t matter if the DVD is bigger.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)