5/3/2021 0 Comments Image Corrupt Or Truncated.
For (data) CD-ROMs and DVDs that are imaged to an ISO image, a similar problem exists: how can we be reasonably sure that the created image is complete In this blog post I will discuss some possible ways of doing this using existing tools, along with their limitations.I then introduce Isolyzer, a new tool that might be a useful addition to the existing methods.A seemingly obvious solution would be to do a checksum comparison on both the ISO image and the physical carrier.In some tests I did over a year ago, I ran into a a very strange issue where my attempts to image a CD would sometimes result in incomplete reads, and, as a result, truncated ISO images.
![]() The problem was most likely caused by faulty hardware (the machine on which I ran those tests more or less died shortly afterwards). Most worryingly, the machine would sometimes return incomplete data, both while creating the ISO image as well as during the subsequent checksum calculation on the physical carrier. The result of this was that the computed checksums were identical in both cases, which meant that the image passed the checksum quality check, even though it was incomplete. Most of the tests in isovfy were added after bugs were discovered in early versions of mkisofs. ![]() The documentation of the tool isnt very clear about what specific checks it performs. In one of my tests I fed it an ISO image that had its last 50 MB missing (truncated). This did not result in any error or warning message Most of the reported isovfy errors that I came across in my tests simply reflected the file system on the physical CD not conforming to ISO 9660 (this seems to be pretty common). The ISO 9660 page on the OSDev Wiki gives a good explanation of the internal organisation of an ISO 9660 image. From this I learnt that the Primary Volume Descriptor (which is a data structure that is present on all ISO images) contains two interesting fields. To test this, I wrote a Python script that parses an ISOs Primary Volume Descriptor fields, calculates the expected file size and then compares this against the actual file size. Running the script against some 20 ISO images I had lying around showed that for 7 files the expected size was indeed identical to the actual file size. For most images, the actual size turned out to be marginally larger than expected (typically about 300-600 kB). For 3 images, the actual size was about twice the expected size. Digging deeper, I found out that these were hybrid images that contain an Apple partition on top of the ISO 9660 file system. According to this Wikipedia article, these hybrid discs come in two varieties. These contain a Master Directory Block (located at 1024 bytes into the discimage). Using the information here and here I was able to add detection of such hybrid images to my code, as well as a simple parser for the zero block structure that contains two fields that define the partitions size: Block Size and Block Count. For my hybrid images, multiplying both figures resulted in a value that was close to (but again marginally smaller than) the actual file size. The Master Directory Block also contains Block Size and Block Count fields that allow one to calculate the size of the file system. Do others find this useful Are things missing (i.e. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |