[NTLUG:Discuss] iso md5sum question

[Robert Pearson]

On Sat, Nov 8, 2008 at 8:52 PM, Fred James <fredjame at fredjame.cnc.net> wrote:
> Robert Pearson wrote:
>> (omissions for brevity)
>> There is something wrong with your MD5SUM text file.
>> There should be an ISO file for each image at that URL. There will be
>> a text file containing the MD5SUM's for all the images.
>> Some times I just cut and paste the MD5SUM file contents to a local
>> text file. Other times I download the text file.
>> The format of MD5SUM files seems to vary. Sometimes I have to adjust
>> the contents of cut and paste or downloaded.
>> Not the MD5SUM number.
>> Sometimes the file name in the MD5SUM file extension is different than
>> the one downloaded.
>> Sometimes the position in the line is wrong.
>> Sometimes there is extra information in the file that my version of
>> MD5SUM will not process.
>> It does not seem to be a perfect world but it does work if you read
>> the "man" pages or Google md5sum usage.
>>
>> The process is to trust the MD5SUM number generated by the download
>> site and normally in their MD5SUM text file.
>> Re-computing it locally and manually comparing the two is one way to
>> do it but more error prone than having the MD5SUM program do it.
>> I use K3b to burn with and it computes an MD5SUM and allows you to
>> enter a comparison number. Usually I check after download and again at
>> burn time. I also run "media check" at install time. These checks have
>> saved me a lot of time.
>>
>> If the MD5SUM's do not match it saves your time making a disc coaster
>> and trying to install it.
>>
> Robert Pearson
> Thank you for your reply and the clarification - I did read the man
> pages

My point was not clear and I was incorrect. The MD5SUM file format is
not in the "man" pages. It's been a while...
To find the MD5SUM file format do (or Google "md5sum usage"):

info coreutils 'md5sum invocation'

`--check'
Read file names and checksum information (not data) from each FILE
     (or from stdin if no FILE was specified) and report whether the
     checksums match the contents of the named files.  The input to
     this mode of `md5sum' is usually the output of a prior,
     checksum-generating run of `md5sum'.
* Each valid line of input consists of an MD5 checksum, a binary/text
flag, and then a file name.
* Binary files are marked with `*', text with ` '.
* For each such line, `md5sum' reads the named file and computes its
MD5 checksum.
  Then, if the computed message digest does not match the
     one on the line with the file name, the file is noted as having
     failed the test.  Otherwise, the file passes the test.  By
     default, for each valid line, one line is written to standard
     output indicating whether the named file passed the test.  After
     all checks have been performed, if there were any failures, a
     warning is issued to standard error.  Use the `--status' option to
     inhibit that output.  If any listed file cannot be opened or read,
     if any valid line has an MD5 checksum inconsistent with the
     associated file, or if no valid line is found, `md5sum' exits with
     nonzero status.  Otherwise, it exits successfully.

I found this very helpful. Especially with multiple files in the old
4-6 "CD" days. Less so now with DVD's.
Many of the MD5SUM files I downloaded did not follow this "valid line"
format. The check sum was always correct.
I found some variance in the Google search results but I tried them
all until I got one that works for my version of MD5SUM.
Consistently.

 - the take away message seems to be that if the sums match the
> file is at least the same as the original (regardless of the output from
> the -c option),  That is good to have confirmed.
>
> As far as matching the two long numbers - I just put each one into a
> different file and run diff against them - shouldn't be any error there
> - either they match or they don't.
> Regards
> Fred James
>
>
> _______________________________________________
> http://www.ntlug.org/mailman/listinfo/discuss
>