Or you can create an md5 sum of dvdsig.md5.
Clever!
Does that make sense?
OK, I just copied and pasted dvdsig.md5 from here-
Then used MD5 Summer (postcardware)
to create an md5 sum of the pasted dvdsig.md5 file, ended up with
this-
1271797eb445f2a231ccd017e8ac1b2a *dvdsig.md5
Can anyone confirm this with the CD version of dvdsig.md5.
1.txt,1271797eb445f2a231ccd017e8ac1b2a (PL file) *
1.txt,c243c069a685e2050e87b264e12264b8 (CD file)
1.txt,4c0ca02cf1f49191f867ab43f833be43 (dump CD to drive)
I did get the same value for the PL file.
I had to rename the files, as .md5 files are skipped. I got different
checksums for the checksum file when I copied the CD .md5 file to
disk and when I copied the entire CD to disk and reran the checksum
program???
It looks like the checksum program did not recreate the .md5 file in
the same order in which the PL file is created. I just scanned the
first page full and I see differences between the order of files and
directories.
It looks like it is going to be necessary for the end user who wants
to verify the files to copy the CD to hard disk in order to run the
checksum program. The program reads and writes to the current
directory, checking all subdirectories, rather than having the ability
to run from hard disk and doing the files on a CD.
I can write a small program with the PL file hard coded that will
check user created file lines and report any that are not identical.
That is, a line for line check in which line order does not matter.
Only the content of an entire line is compared to the PL file for
exact matches.
Short of that, it is far too tedious to read and compare 32 hex digit
strings manually. Does anyone else have other ideas?