F12-i386-DVD iso won't burn properly -- SOLVED

Mike McCarty Mike.McCarty at sbcglobal.net
Wed Mar 3 06:37:19 UTC 2010


Tim wrote:
> 
> It wasn't that chicken-and-egg situation that I was referring to, but
> the long standing issue that the self check has been bad for a very long
> time.  If *something* *else* can manage to not read past the end of the
> disc, why can't it?

Ok, I misunderstood what you were referring to. Yes, that should
be checkable, but that's not the best check. It would be better to
put MD5 (or SHA1) sums inside the file system, and check the files,
rather than the image, anyway. That obviates the entire problem, and
provides a better check.

[...]

> You'd have a routine that asked for a checksum to be inputed, from some
> other source, and the disc to be checked against it. 

Not necessary. Check the files from *inside* the file system,
not outside. All files get an MD5 or SHA1 check performed on
them, except for the one file which has all the sums. That one
simply gets a CRC (since it won't be very big). There are already
means to embed such a CRC in the program which does the checks.
It can then check itself first, via CRC, then perform the
MD5 or SHA1 checks on all the other files.

That is, for self-checks. The program first checks itself via
CRC, then checks the files on the image, then asks for all
the other discs. It has the MD5 (SHA1) sums for all the others.
For those reads, you would want to mount the disc, and then
check the files inside the file system.

For checks of basic downloads, and burt images (not self-checks)
you'd want to be able to do what you suggest.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!


More information about the users mailing list