Basically what I would like to do is to verify that an image has been burned successfully. It's pretty much the same question like this, except for Mac OS X.

After searching online (including superuser.com) I could only find solutions to my problem for Windows and I would like to solve this problem on Mac OS X.

I already tried to install ImgBurn via Wine but that doesn't seem to work.

  • I discovered a workaround to my problem, but it doesn't seem to be a proper solution. What I did is making a DVD/CD-Master-Image with Disk Utility (.cdr) from the drive which apparently matches the .iso-Image's checksum. I would appreciate a better solution where I wouldn't need to do reserve some disk space before making a checksum. – comfreak Sep 2 '15 at 21:05

The best way to go about this sort of comparison on is the cmp command. cmp compares data byte-by-byte and will inform you of any difference** between the two files.

Enter the command as cmp /home/image.iso /media/cdrom0 (make sure to use the actual paths to the image and the CD as appropriate for your situation). The output you want to see is either no output (the image and the CD are identical), or cmp: EOF on image.iso, which indicates that there are more bytes on the CD than the image, but all of the data on the image was successfully copied to the CD. The extra data on the CD is probably just padding with zeroes, which occurs when the image is smaller than the size of the CD.

On the other hand, if you see an output informing you that the two differ (it will look something like image.iso cdrom0 differ, byte 128 line 7), then there was an error when copying the image and there is some difference between them. The other thing you might see that would not be good would be cmp: EOF on cdrom0, as this indicates that part of the image was not copied to the CD (this could be the result of an interruption in the copying process).

As a side note, I would guess that the reason you're seeing a different shasum for each file is because of that zero padding at the end of the CD, which will change the shasum but won't affect the functionality at all.

** Technically, cmp only reports the first difference between the files. If there are multiple differences, it won't show them, but for the case of burning an image to a CD the number of errors shouldn't matter, any errors are bad.

  • 1
    Awesome! This solved my problem, without having to make an image of the CD before comparing. I figured you need to compare the image with the corresponding drive in /dev/rdiskX (where X is different for each drive) like this: cmp /Users/JohnDoe/image.iso /dev/rdiskX. You can figure out the number of the drive via "Disk Utility" by clicking on the drive and then the "Info" button at the top. – comfreak Sep 4 '15 at 16:26

I'm not a Mac user myself, but after doing a bit of snooping, it would seem that this is supported natively in OS X, thanks to the Disk Utility application. Details here: http://www.macinstruct.com/node/390

This article is from 2011, and like I said I'm not a Mac user myself so I don't have one on hand to check, but if Disk Utility still exists this option is probably still there.

  • If I read it correct, then this only refers to the verification right after burning the disc. What I am looking for is a way to verify discs after this option is already gone because the disc was burned in a different way or at a different time. – comfreak Sep 2 '15 at 19:30
  • Humm, interesting... If you're copying the iso with dd it should be a bitwise copy, so... You could try diff, eg diff /home/myfile.iso /media/cd0, although if the shasums were not the same I'm not sure if that would work. There's also cmp, you might have a bit more success with that. Similar command, cmp /home/myfile.iso /media/cd0, and then you're looking for either no output (they're identical) or EOF on myfile.iso which just means there's padding at the end of your CD. Those are both Linux commands, but I'm pretty sure they both exist on OS X. – realityChemist Sep 4 '15 at 13:11
  • It seems like your comment moved to the wrong answer, but I am still going to add mine here. I tried both diff and cmp on Mac OS X (they do exist) and it seems I can't get them to match with diff. I tried running diff /home/image.iso /dev/rdiskX but the only result was Binary files /home/image.iso and /dev/rdiskX differ. With cmp I get EOF on /home/image.iso, does that mean it matches till the end of the file of the image, meaning the disc is fine? – comfreak Sep 4 '15 at 14:52
  • Yes indeed! If you're seeing EOF on /home/image.iso what that means is that cmp ran out of bytes in the iso file first, but everything before the end of the iso file was identical. The CD has more bytes, which probably just means that the iso is smaller than the size the CD can store and the end of the CD was just padded out with zeroes. tl;dr the iso was successfully written to the CD with no errors! Would you like me to add this an an answer? – realityChemist Sep 4 '15 at 15:13
  • I went ahead and added it as an answer, see below. Hope people find this useful! – realityChemist Sep 4 '15 at 15:46

If you are not afraid of "the dark side" of OSX i.e. use a terminal for that you can simply compare the SHA checksums of the raw device and the image file.

$ shasum /dev/rdisk2
bad2c8fbb090a4b49b63135895fdb3b64062ceb6  /dev/rdisk2
$ shasum yourdisk.iso
bad2c8fbb090a4b49b63135895fdb3b64062ceb6 yourdisk.img

and compare the output.

  • I actually already thought of this and tried it out but like this: dd if=/dev/rdiskX ... | shasum. Either way it doesn't match, even though I am very confident that the disc burned successfully since the tool I burned it with reported a success. I even went to a windows machine to try out "ImgBurn" just to make sure this solution doesn't work and the result was that the disc was just fine. – comfreak Sep 2 '15 at 20:40

Assuming bash scripting is available

Copy the bash-script below as 'cksum.sh' into a folder that is included in your $PATH
Type chmod 755 cksum.sh (within the folder you saved the script in)

Then to use it; cd into the folder with the original files, and do:
$ cksum.sh -b to create a 'CONTENT.sha256sum' file.
$ cksum.sh -c to check the checksums in the file against files in the current dir.

You may also provide a filename for the checksums as a second argument, to override the default, which is always created in/read from the current working dir (note: excluded from the checksum file).

This is most certainly slower than many other solutions, but I believe it is more versatile than others. Note also that if you leave the checksum file on the media (be it CD, DVD or USB) then checking the media content is a simple
sha256sum -c CONTENT.sha256sum
at any time, assuming you have the sha256sum executable.

It detects faulty and missing files, but not 'added files' (as written); but that is possible by matching the folder content to the list content.

The end user may also detect faulty (e.g. read errors) and replaced files by finding the sha256sum executable and using sha256sum -c CONTENT.sha256sum.

--- cksum.sh ---



case  "$1" in

  "-b" ) 
    ( find -type f ! -iname "*$file" 2>/dev/null   \
     | while read f ;do sha256sum -b "$f" ;done )  \
     | tee "$file"

  "-c" )
    if [ ! -r "$file" ] ;then
      echo "'$file' is not a readable file, cannot check."
      sha256sum -c "$file"

  * )
    echo "Usage: ${0##*/} -b|-c [checksum-filename]"
    echo "Will create(-b)/check checksums in '$file'"
    echo "for files in current dir,"
    echo "by use of 'find -type f' and 'sha256sum -b/-c'"

  • Thanks for putting that much effort into answering my question. However, I think that comparing it with cmp would be a better solution, if you didn't just burn an image of a few files but something like a Linux-Image. Those images are typically created with a different file-system that might not be able to be mounted by Mac OS X or may be even having multiple partitions. Apart from that, would this solution detect missing files? – comfreak Sep 4 '15 at 20:48
  • Assuming you have a 'missing' file in the file (CONTENT.sha256sum), it would detect it; sha256sum would complain about that :-) - this also allows to find duplicate files as the checksums would be the same. As there should be a sha256sum for each and every OS, it should be possible for the destination OS user to detect missing and faulty files. – Hannu Sep 5 '15 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.