I have an ISO file that I've burned to a CD. I know its md5 checksum. On my Ubuntu 9.04 system I can do
dd if=/dev/cdrom | md5sum
and I get the same checksum as for the original ISO file. However, on my Windows XP machine with CoreUtils 5.3.0, when I do
dd if=\.\D: 2>nul: | md5sum
I get a different checksum (D: is the drive letter for the CDROM). I get the same result if I drop the "2>nul:", but the stderr text gets from dd gets mixed with stdout from md5sum so it's more tricky to read the checksum.
Can anyone see what I'm doing wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-08-26
Why the extra pipe? Does md5sum /dev/cdrom work on Linux? Does md5sum \.\D: work on Windows? Is the md5sum you are using from gnuwin32? (I don't see any md5sum package in http://gnuwin32.sourceforge.net/packages.html )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason for the extra pipe is that I found a hint somewhere on the worldwide web that piping dd into md5sum was the way to get a CD checksum, because you want to be summing the entire ISO image of the disk, not just the disk contents.
But you're right - md5sum /dev/cdrom works on Ubuntu, giving the correct answer, and md5sum \.\D: with GnuWin32 gives the same wrong answer on Windows, do the dd is superfluous.
One thing I have noticed is that "df" on both Ubuntu and Windows reports the CD size as 476630 1K blocks. However, "dd bs=1k" on Ubuntu reports that it has processed 476930 blocks (300 more than there are on the CD) while on Windows it reports 476630.
Also, if I do "dd bs=1k count=476630" on Ubuntu, I get the same checksum as I do on Windows. Which means that Ubuntu is finding 300K more on the CD that Windows is seeing.
Am I runnning into some bizarre blocksize issue? Or does \.\D: on Windows give me the mounted contents of the ISO 9660 image, while /dev/cdrom on Ubuntu gives me the raw disk image (which is what I need).
So the bottom line seems to be - how do I get at the raw CD disk image in Windows, because \.\D: isn't giving it to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The format \.\D: seems indeed the correct one for opening a physical volume, according to the description for CreateFile on MSDN (http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx). Also, the GnuWin32 md5sum \.\D: gives the same result as the CygWin md5sum \.\D: and md5sum /dev/scd0. So, I'm at a loss as to what is going wrong here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have also noticed stderr mixing with stdout on some programs I have that use
crt. Even if you are not buffering stdout, and stderr isn't buffered
(default), and regardless of flushing, the text can mix under certain
circumstances (like piping). I have not found a solution despite a lot of
experiments. You can do something like this though pipecmd1 | pipecmd2
2>err | pipecmd3 .
cmd2 is the mixed out/err output
t i ff/ 0.2 /ti f f - 0 . 2 - b i n . z i p
so rt : c l o s e f a i l e d : -
To your question, I've encountered the hash issue before and if I remember
correctly what happens is the (zeroed) sectors at the end are not
added/compressed in the hash value. Discussed briefly here:
I have an ISO file that I've burned to a CD. I know its md5 checksum. On my Ubuntu 9.04 system I can do
dd if=/dev/cdrom | md5sum
and I get the same checksum as for the original ISO file. However, on my Windows XP machine with CoreUtils 5.3.0, when I do
dd if=\.\D: 2>nul: | md5sum
I get a different checksum (D: is the drive letter for the CDROM). I get the same result if I drop the "2>nul:", but the stderr text gets from dd gets mixed with stdout from md5sum so it's more tricky to read the checksum.
Can anyone see what I'm doing wrong?
Why the extra pipe? Does md5sum /dev/cdrom work on Linux? Does md5sum \.\D: work on Windows? Is the md5sum you are using from gnuwin32? (I don't see any md5sum package in http://gnuwin32.sourceforge.net/packages.html )
md5sum is part of CoreUtils 5.3.0, as is dd.
The reason for the extra pipe is that I found a hint somewhere on the worldwide web that piping dd into md5sum was the way to get a CD checksum, because you want to be summing the entire ISO image of the disk, not just the disk contents.
But you're right - md5sum /dev/cdrom works on Ubuntu, giving the correct answer, and md5sum \.\D: with GnuWin32 gives the same wrong answer on Windows, do the dd is superfluous.
One thing I have noticed is that "df" on both Ubuntu and Windows reports the CD size as 476630 1K blocks. However, "dd bs=1k" on Ubuntu reports that it has processed 476930 blocks (300 more than there are on the CD) while on Windows it reports 476630.
Also, if I do "dd bs=1k count=476630" on Ubuntu, I get the same checksum as I do on Windows. Which means that Ubuntu is finding 300K more on the CD that Windows is seeing.
Am I runnning into some bizarre blocksize issue? Or does \.\D: on Windows give me the mounted contents of the ISO 9660 image, while /dev/cdrom on Ubuntu gives me the raw disk image (which is what I need).
So the bottom line seems to be - how do I get at the raw CD disk image in Windows, because \.\D: isn't giving it to me.
The format \.\D: seems indeed the correct one for opening a physical volume, according to the description for CreateFile on MSDN (http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx). Also, the GnuWin32 md5sum \.\D: gives the same result as the CygWin md5sum \.\D: and md5sum /dev/scd0. So, I'm at a loss as to what is going wrong here.
I have also noticed stderr mixing with stdout on some programs I have that use
crt. Even if you are not buffering stdout, and stderr isn't buffered
(default), and regardless of flushing, the text can mix under certain
circumstances (like piping). I have not found a solution despite a lot of
experiments. You can do something like this though pipecmd1 | pipecmd2
2>err | pipecmd3 .
cmd2 is the mixed out/err output
t i ff/ 0.2 /ti f f - 0 . 2 - b i n . z i p
so rt : c l o s e f a i l e d : -
To your question, I've encountered the hash issue before and if I remember
correctly what happens is the (zeroed) sectors at the end are not
added/compressed in the hash value. Discussed briefly here:
http://article.gmane.org/gmane.os.cygwin/103991