aritchie

Thanks again. Do you know of any tools that could perform validation of the ISO image or disk to know whether it could give rise to problems (without actually having to find a system on which the disk actually fails)? I'm trying to remember which of the OS platforms we support actually mount the UDF filesystem by default - might be Linux or Solaris. If it's Solaris then it wouldn't support Joliet (only RockRidge - don't know if it would fall back to ISO9660 either) so they might be suitable test systems but if there is some tool I could run to check an image, then that might be easier.

Hi Support, We're using ImgBurn to create our ISO images for our product, and this seems to be fine. I have a question about a discrepancy between the file size of the ISO image and the size of the DVD (burnt from that ISO image) in Windows Explorer. In all the instances I've checked, the Windows Explorer reported size of the DVD is smaller than that reported for the ISO image. If I open the DVD in either ImgBurn or ISOBuster, or rip the DVD using ImgBurn or ISOBuster, then I see/get exactly the correct size which matches the original ISO. However, a colleague of mine is using a tool called MagicISO to rip the DVD's I send to an ISO image (don't ask why they can't just take the ISO I created) and the ISO that this creates has a size identical to the one displayed by Windows Explorer. If I then compare the ISO I created with the ISO created by MagicISO, I see that the only difference is that the ImgBurn ISO contains additional zero-byte padding at the end of the image. All files/directories within the ISO images are present and correct. This causes us a problem because the MD5's generated for both ISO's are different (because of these additional bytes). Can you explain why they are being added and is there a way to disable the adding of these bytes or, alternatively, make the reported DVD size agree with the ISO size? (I suspect that MagicISO is using the content size to rip just that number of bytes rather than whatever other parameter gives the full image size and - whilst I think that is probably wrong - I'm not sure I can dissuade them from using it in favour of ImgBurn as they have actually purchased a license for it and have been using it successfully for 5yrs). As an aside, is there any way, or tool, to look at what information is being recorded in the DVD Header, with respect to these size parameters? Regards, Andrew

OK - thanks for that. I think I understand what you're saying regards for 2) - but that would only give me the combined size of all the included filesystems - is there any way to report on the size of each individual filesystem and, if not, could that be provided in a future release? I know it's not life or death - if you need a filesystem then you need a filesystem - but it may be useful to assess the impact of choosing to use a particular filesystem over, say, altering file naming to fit in with a more restrictive filesystem (e.g. using ISO9660 level 0 or 1 as opposed to UDF - as, choosing UDF, appears to have added nearly another 100MB to the image size in our case, up from about 60MB with IS09660+Joliet combined to about 160MB). Lastly, for 1) could the ability to specify logging thresholds be made configurable in a future release? Regards, Andrew

Is it possible to disable ImgBurn from giving up logging of a particular type of warning/error after 1000 occurrences? I'd like to see all such occurrences of warnings/errors, even though this may mean a substantially bigger log file. Is it possible to log the size of the final filesystems being generated for an image? i.e. how much space do each of the ISO9660, Joliet and UDF filesystems take up within the image? Is it possible to describe what criteria ImgBurn uses for identifying duplicated files (when using the "Optimize duplicate files" option? Is it filename/filesize/filedate or MD5 or some combination of these and/or some other criteria?

It appears as though the behviour I am seeing on Solaris 8 is a know problem on Solaris 8 & 9 (as detailed on the following page) http://woce.nodc.noaa.gov/wdiu/updates/mount_dvd.htm I'm running a test with just a UDF file system. Secondly, I noticed that on an HP-UX system, everything is displayed correctly but does have the ";1" text at the end of every file - which I believe I could remove using the appropriate ISO9660 option in ImgBurn. Interestingly, 'mkisofs' fares worse in that it not only displays files with the ';1' text at the end but also displays all names in uppercase only. (I think there are appropriate options in 'mkisofs' to address this - if I was allowed to use it :-().

> To be honest, I'd be amazed is Solaris supports UDF when it doesn't appear to support Joliet. I can get the disk to mount properly if I specify the "-o nomaplcase" switch. (Solaris does have a "-o Joliet" switch but when I used it, thhe mount command said it was ignoring it). What I'm trying to do is get the ImgBurn generated DVD to behave in the same way as a 'mkisofs' generated disk behaves in order that the "experience" for users is the same. > If mkisofs is working ok for you, why not stick to it? Unfortunately, our legal department is concerned that, because 'mkisofs' is covered by the Gnu Public License, there is a "possibility" that if it injects anything into the image (like Volume set info) then that "could" mean we have to make the source of anything packaged with that tool available with the tool. In order to be "risk free" they have advised us not to use it. In ImgBurn, I thought that I had finally found a worthy successor without any restrictions and which supports the "duplicate-once" feature of 'mkisofs' (which we rely upon to avoid us having to ship more than one DVD).

OK - I'll give that a try and let you know. Would your recommendation be to use "ISO9660 + Joliet + UDF" with the previously specified options set for ISO9660 and Joliet? Should I select any UDF specific options?

Hi, I am trying to make the switch to using imgburn instead of mkisofs but am hitting some problems with OS compatibility. The ISO image that I'm generating, when burnt to disk, is not displaying properly on all OS'es. I need to produce an ISO which, when burnt to DVD, can be mounted and displayed correctly on the following OS'es AIX, HP-UX, Linux, MacOSX, SolarisIntel, SolarisSparc, Windows I had no problems when using 'mkisofs' with the options -J (Generate Joliet directory information) -l (Allow full 31 character filenames for ISO9660 names) -r (Generate rationalized Rock Ridge directory information) -duplicate-once (Optimize storage by encoding duplicate files once) -allow-leading-dots (Allow ISO9660 filenames to start with '.' (violates ISO9660)) However, when using ImgBurn, and selecting "ISO9660 + Joliet" filesystems (no UDF as it's not a Video disc that I'm generating) with the following options ISO9660 Level 2 - 31 Characters (also tried it with "Level X - 219 Characters) ASCII Character Set Allow More Than 8 Directory Levels Allow Files Without Extensions Joliet Level 1 - 64 Characters Allow Files Without Extensions Tools->Settings->Build->Page 1 Optimise Duplicate Files The resultant DVD, when automounted on a SolarisSparc system, displays all files and directories in lowercase. Joliet based OS'es (like Windows and MacOSX display fine). A 'mkisofs' generated DVD displays fine. When looking at how Solaris has mounted the disk I can see the following /vol/dev/dsk/c0t0d0/dvd /cdrom/dvd hsfs ro,nosuid,noglobal,maplcase,rr,traildot What I think is the significant item here is the "rr" flag - indicated support for the Rock Ridge extensions. I think this cannot be enabled for ImgBurn. Are there any options for selecting this support or should I be using other options in ImgBurn to achieve the same result? I can provide the settings/project files I'm using if necessary. Regards, Andrew