I have not tried this yet, but the statement is that "The cmp utility
compares two files of any type and writes the results to the standard
output."
Will this work for mount points or device special files that are mounted
on mount points, allowing one to compare two full directory tree
hierarchies?
That is, using the situation elaborated below (that is, earlier in this
thread), will
cmp /dev/loop0 /dev/sr0
compare the ISO image and the original mounted DVD (after driver error
correction, if any) "byte by byte"?
On a separate issue, when burning a DL DVD-ROM (single sided,
approximately 8 Gbyte storage), is there a difference between a DVD+R
and DVD-R in the final physical product? If so, is there a mechanism
(software) to determine if the source DVD being cloned (copied) is -R or
+R ? All of the mechanisms I have found (to date) report the source DVD
as a DVD-ROM, with no indications of +R or -R.
Yasha Karant
On 11/05/2013 05:43 AM, Nico Kadel-Garcia wrote:
If you're in a rush, comparing the file sizes and the "sum" command
output, rather than the computationally intense md5sum, gives a much
faster verification of two orthogonally related components. While not
as certain as md5sum, the orthogonal verification of the size adds
considerable verification.
However, in this case, it's pointless to use checksums. Simply use the
"cmp" command, which compares the bytes of the files in question.
On Mon, Nov 4, 2013 at 8:07 PM, Yasha Karant <[email protected]> wrote:
On 11/04/2013 04:53 PM, ToddAndMargo wrote:
On 11/04/2013 04:21 PM, Yasha Karant wrote:
I need to do a media comparison between a data DVD and the .iso file
that purportedly contains the image of the exact DVD (including any
bootable or autoload binary files, not for an Intel instruction set
architecture).
When burning to the DVD, applications such as K3B and Nero (for Linux)
will do a verify of the burned media. My understanding is that these
applications go through the device driver and device controller
hardware/firmware that may be applying error correction to the raw bit
stream; any such detected "hardware media" errors typically are reported
by the driver to a log file, but typically (if corrected) do not cause
the application to fail.
If one mounts the .iso file, by a command similar to that below,
# mount -t iso9660 -o ro,loop=/dev/loop0 /files/dvdimage.iso
/media1/virtualdisc
and likewise has the physical DVD in the DVD drive and mounted from,
say, /dev/sr0
will a diff /dev/loop0 /dev/sr0 suffice?
Is there a utility that will do the same thing that Nero would do as it
verifies after burning, but not requiring the burn -- that is, verify a
DVD against an ISO image file?
If /dev/sr0 were mounted on, say, /media/someDVD, and the ISO image
file on
/media1/virtualdisk , is there a utility or script to do a "bit by bit"
comparison via the mount points (not just the "raw" mount as /dev/sr0 )?
Yasha Karant
Hi Yasha,
Check the DVD as a raw device.
After you burn the ISO, eject the DVD (clears out something,
I don't know what, but had to learn the hard way):
/usr/bin/eject /dev/sr0
Then inject the DVD (close the door). Can be on the same
line.
/usr/bin/eject -t /dev/sr0
Then make an MD5SUM of each
md5sum /files/dvdimage.iso /dev/sr0
Eyeball the sums. One will be on top of the other.
If you like, I have some leftover code I can send you.
-T
From http://en.wikipedia.org/wiki/Md5sum
As with all such hashing algorithms, there is theoretically an unlimited
number of files that will have any given MD5 hash. However, it is very
unlikely that any two non-identical files in the real world will have the
same MD5 hash, unless they have been specifically created to have the same
hash.
End quote.
I explain the above reality to my students, although I do use MD5SUM myself.
I was hoping for a utility that did a true bit-by-bit comparison of the two
files.
Aside: Note that a (very) clever attacker can embed specific issues into a
file such that the corrupted (and perhaps infected) file will pass a MD5
hash test. Note that USA NSA and other entities often do employ such clever
persons (do recall the cyber attack on the fissile material enrichment
facilities of a Middle Eastern nation state not in full agreement with USA
foreign policy, albeit an attack not specifically limited to this
mechanism). I am not suggesting that the DVD and ISO image file I am using
are subject to this sort of clever corruption; but, it is important to
understand the limitations of certain techniques.
Yasha Karant
