Jump to content











Photo
- - - - -

case change of files/folders when mounting Avira ISO


  • Please log in to reply
31 replies to this topic

#1 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 October 2012 - 07:49 PM

If I mount the Avira Rescue ISO from here and mount it under Windows 7 64-bit as a drive volume, the files and folders in the mounted volume are all uppercase, so that when I copy the files to a bootable USB drive, I get an error when it boots due to the case of some files being wrong.
If I use 7Zip then the files are correctly shown and extracted as lowercase. Presumably this is due to the way the ISO was originally prepared by Avira?
Apologies if this has been mentioned before.
This does severely limit the usage of ImDisk for mounting ISO's and copying files from it though, as it seems I cannot trust ImDisk...

#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 19 October 2012 - 11:09 PM

If I mount the Avira Rescue ISO from here and mount it under Windows 7 64-bit as a drive volume, the files and folders in the mounted volume are all uppercase, so that when I copy the files to a bootable USB drive, I get an error when it boots due to the case of some files being wrong.
If I use 7Zip then the files are correctly shown and extracted as lowercase. Presumably this is due to the way the ISO was originally prepared by Avira?


Question is more what is correct and what is not correct. The iso image your link points to, contains a standard old ISO9660 image. Such images have an "undefined case" in filenames. The interpretation of characters in filenames as either all uppercase or all lowercase is implementation specific and can vary between operating systems. Now, for historical reasons, Windows cdfs.sys filesystem driver report all filenames on such volumes as all uppercase. Many Unix ISO9660 filesystem drivers report them as all lowercase. This of course introduce risks in applications where you transfer files between systems with different interpretation of filename case, or in general when using filename case-sensitive applications.

Now, back in the days of developing Windows 95, Microsoft realised that this would be a problem if not solved as quick as possible. They introduced an extension to ISO9660 filename namespace, called "Joliet". It allows case-insensitive but case-preserving filenames on otherwise ISO9660 volumes. To comply with ISO standards, a Joliet image mastering also create parallel ISO9660 compatible filenames (see for example if you run mkisofs -J or similar). The "Unix world" introduced a similar ISO9660 extension called Rock Ridge. It solves pretty much the same thing, but it is both case-preserving and case-sensitive, as well as in other respects more or less fully Posix filesystem compatible.

Now, almost 18 years later, almost all CD/DVD data images are mastered with at least three filename namespaces. Standard ISO9660, Joliet and Rock Ridge. But the Avira image in this case, has only the standard ISO9660 namespace and nothing else. This is still reasonably common for example for bootable operating system setup images or similar. This leaves cdfs.sys in Windows to using standard ISO9660 namespace for filenames, which it will present to the operating system as upper case.

This does severely limit the usage of ImDisk for mounting ISO's and copying files from it though, as it seems I cannot trust ImDisk...


Yes, unfortunately it does. The same applies to all solutions involving use of a virtual CD/DVD device to present the ISO image to the operating system as virtual CD/DVD media. You would also see the same results if you burn the image directly to physical CD/DVD media. In all these cases the filenames are read by cdfs.sys which will treat them the same. That is, in this case, uppercase filenames. The disk drivers are not involved in filename convention in any way. Therefore, there is nothing we could do in imdisk.sys to solve this, just like cdrom.sys in Windows cannot solve it for physical CD/DVD devices.

On the other hand, with 7-zip and other archivers, there is no virtual CD/DVD device involved. ISO images are parsed directly within the application in the same way as for example a zip archive. It is therefore in that case up to the archiver application to decide what to do with the filenames. 7-zip developer has decided to go for lowercase. This is in my opinion a good choice. It keeps compatibility with most other usages for files in the ISO images.

#3 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 20 October 2012 - 08:27 AM

Under 7zip, there is a [BOOT] folder (uppercase) but the files and folders are lower case. Is this because 7Zip has recognised that [BOOT] is normally in uppercase and so has chosen to keep it in uppercase?

P.S. Is it possible for ImDisk to recognise these old ISO9660 standard ISOs (or any standard that has the same issue) and warn the user in the GUI application that the file/folder case names will be converted to uppercase and therefore may not be suitable for file extraction/copying? That way we could trust ImDisk so that we would always know if there was going to be a problem?

#4 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 20 October 2012 - 04:58 PM

Under 7zip, there is a [BOOT] folder (uppercase) but the files and folders are lower case. Is this because 7Zip has recognised that [BOOT] is normally in uppercase and so has chosen to keep it in uppercase?


I don't know exactly, but I would guess so too.

P.S. Is it possible for ImDisk to recognise these old ISO9660 standard ISOs (or any standard that has the same issue) and warn the user in the GUI application that the file/folder case names will be converted to uppercase and therefore may not be suitable for file extraction/copying? That way we could trust ImDisk so that we would always know if there was going to be a problem?


ImDisk does not really know anything about filesystem structures. We could of course add some checks (possibly from 7-zip) to the user mode applications before the image is mounted, but would it not be easier to just use 7-zip instead then?

But anyway, this gave me another idea. I wonder if it would be possible to write something that checks for newly inserted CD/DVD media and check if they only has ISO9660 standard namespace. This application could then warn user that filenames are uppercase on that volume and that WIndows will not convert them to lowercase. That way it would work even with other CD/DVD emulation drivers and also with physical CD/DVD media. Ideally, it would then be useful to take this one step further and write a filesystem filter driver that converts file names to lower case on such volumes. But I suspect that part would mean quite a lot of work compared to the problem it solves.

Note that this is at least more technically correct than "filenames will be converted to uppercase". File names are internally stored in uppercase in ISO9660. Even though the standard allows filesystem drivers to convert file names to lowercase when presenting file names to the operating system, nothing requires it (or even recommends it) either.

I seem to recall a problem I experienced in late 90's where a Windows server shared out CD contents across network to clients. One CD had a Linux application on it where Linux clients on the network ran this application directly on the network share. Because this application expected file names in lower case, the application did not work. We finally solved that issue by mounting the network share with a flag on the Linux machine telling it to convert file names from the server to lower case. So, this is not a new problem in any way. But we are talking about standards from late 80's here and I suppose they did not imagine back then that data CD would be used in this way at all. To solve that, I think it would make much more sense for Avira (and others) to use a more modern standard instead to avoid these problems in the first place.

#5 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 20 October 2012 - 08:38 PM

Under 7zip, there is a [BOOT] folder (uppercase) but the files and folders are lower case. Is this because 7Zip has recognised that [BOOT] is normally in uppercase and so has chosen to keep it in uppercase?


I think I can now comment this further, after having looked at the 7-zip source code. It appears that 7-zip detects if the iso image is bootable. If it is, it shows a folder it calls [BOOT] and a file name under there that can be used to access the boot code. There is no real [BOOT] folder in the image, it is just a way for 7-zip to show the boot code image even if the boot code image is not intended to be accessible as a regular file. Similarly, when you open for example an NTFS image with 7-zip, you will notice a folder called [DELETED] under the root folder. In this folder 7-zip shows newly deleted files so that they can be accessed and recovered by user, even though they no longer has an entry in the filesystem directory structure.

#6 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 20 October 2012 - 09:17 PM

But anyway, this gave me another idea. I wonder if it would be possible to write something that checks for newly inserted CD/DVD media and check if they only has ISO9660 standard namespace. This application could then warn user that filenames are uppercase on that volume and that WIndows will not convert them to lowercase. That way it would work even with other CD/DVD emulation drivers and also with physical CD/DVD media. Ideally, it would then be useful to take this one step further and write a filesystem filter driver that converts file names to lower case on such volumes. But I suspect that part would mean quite a lot of work compared to the problem it solves.

Note that this is at least more technically correct than "filenames will be converted to uppercase". File names are internally stored in uppercase in ISO9660. Even though the standard allows filesystem drivers to convert file names to lowercase when presenting file names to the operating system, nothing requires it (or even recommends it) either.

As a first step, when the iso is mounted by ImDisk, the file could be looked at to determine if it is the old standard and just issue a warning.
A filesystem 'lowercase' driver that you suggest sounds like a good idea. Such a driver would be a 'must have' for any user that works with ISOs and would be permanently installed on their OS. I am surprised one does not exist already!

#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 October 2012 - 09:17 PM

Under 7zip, there is a [BOOT] folder (uppercase) but the files and folders are lower case. Is this because 7Zip has recognised that [BOOT] is normally in uppercase and so has chosen to keep it in uppercase?

No.
That is a "convention" used by the Author of 7-zip.
The "[BOOT]" folder does NOT exist at all on the actual CD/ISO, 7-zip creates it and in it puts the actual bootable part of the CD (i.e. either the Floppy Emulation image, the No emulation bootsector or the Hard disk Emulation image).

If you prefer it is a "virtual folder" created by 7-zip to put in it (and thus making it accessible) the "boot" part of the CD which is not actually in the CDFS filesytem.
Compare with this only seemingly unrelated info:
http://reboot.pro/99...__25#entry86679

AND (meant as a shameless plug ;)) do check this also:
http://reboot.pro/12406/
http://reboot.pro/12..._25#entry108486
MKISOFS does write on the actual .iso the command lines that were used to build the .iso (unfortunately genisoimage does not).


:cheers:
Wonko

#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 20 October 2012 - 09:45 PM

Just noticed that some of the files in the iso are uppercase when shown in 7zip or UltraIso - e.g. licensesAVIRA_EULA.txt - ?????
So the Avira iso must be made with some sort of more advanced option than just ISO 9660?

P.S. Win 8 native mount iso feature also mounts this iso as all uppercase files and there is no option/choice presented to mount as lower case...

#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 October 2012 - 10:30 PM

Check the .iso with a hex editor.
You will find:

AVIRA_EULA.TXT;1RR..$NM...AVIRA_EULA.txtPX$

BUT:

GPL_2.TXT;1RR..$NM...gpl-2.txtPX$

The first is "standard" ISO 9660 names (with the now "deprecated" ;1, the second is the RockRidge name, see:
http://en.wikipedia....wiki/Rock_Ridge
(seemingly in an old version implementation)
It seems like the good guys at Avira tried to use the "oldest" standards (possibly in order to get the max compatibility on BIOSes :unsure:)

All, in all there is no real mistery, some tools will use the ISO 9660 names, some other (including 7-zip) are using the RockRidge ones.

Try (see the already mentioned thread) using ISOINFO like this:
isoinfo -l -i <path>rescue_system-common-en.iso>CDDIRISO.TXT

isoinfo -l -R <path>rescue_system-common-en.iso>CDDIRRR.TXT

and compare the results ;).

:cheers:
Wonko

#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 20 October 2012 - 10:45 PM

Thanks.
Seems to me that by the year 2012, Windows 8 could have a better cdfs that actually takes note of these extensions!

#11 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 20 October 2012 - 11:22 PM

As a first step, when the iso is mounted by ImDisk, the file could be looked at to determine if it is the old standard and just issue a warning.
A filesystem 'lowercase' driver that you suggest sounds like a good idea. Such a driver would be a 'must have' for any user that works with ISOs and would be permanently installed on their OS. I am surprised one does not exist already!


I agree. Ideally, it would have been useful with for example a registry setting for cdfs.sys that changed the behaviour to lower case for non-Joliet CD/DVD media.

P.S. Win 8 native mount iso feature also mounts this iso as all uppercase files and there is no option/choice presented to mount as lower case...


Again, this has nothing at all to do with the actual virtual or physical CD/DVD driver. It happens at filesystem level. It is the same cdfs.sys filesystem driver that handles this for both ImDisk drives, the drives created by Windows 8 "native" virtual CD/DVD and for physical CD/DVD media under Windows 8. If there were an option to convert file names to lowercase, it would have been available for all kinds of CD/DVD drives, virtual or not.

Seems to me that by the year 2012, Windows 8 could have a better cdfs that actually takes note of these extensions!


In Windows, the cdfs.sys filesystem driver is described as "ISO9660/Joliet File System Reader for CD/DVDs". It seems that Microsoft had never had any intention to support Rock Ridge. I seem to recall that there were discussions about this back in mid-90's, where many people did not like the idea that Microsoft went for their own ISO9660 namespace extension, Joliet, while other operating systems used extensions to Rock Ridge instead (AmigaOS, SunOS, OS/2, MacOS etc).

I found some old, but generally good, information about CD/DVD filesystems here: http://www.isobuster...lp/file_systems

Some history:
SCO Unix mount command for CD/DVD had an option to convert upper to lower case: http://uw714doc.sco....nt_cdfs.1M.html
Windows NT 3.1 and 3.5 had a problem in cdfs.sys where it did not even accept a file open request that specified name in lower case: http://support.microsoft.com/kb/123067 (This made the filesystem case-sensitive, which is generally bad practice for a filesystem driver in Windows. Most Win32 application expect to be able to open a file by specifying either ABC.BIN or abc.bin. They also expect to get the same file in both cases.)

#12 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 21 October 2012 - 09:10 AM

@steve, let me see if I understand you. For your convenience, you want imdisk not to follow a standard :o ?

Avira is respecting the (old but unchanged) standard; there are tools to extract whichever "version" of the files that the original ISO image builder included in the specific ISO image; yet you want to use imdisk so you suggest imdisk should be able to "break" from the standard. That sounds very much like a MS practice :).

FWIW, Isobuster can show you each and all standards that were included in the specific ISO image. If the ISO image has only ISO9660 filenames, you will see 2 "ISO" trees (one for Big Endian, one for Little Endian). If the ISO image also has "extensions", Isobuster will show you them too (Joliet and/or RR for example). Strangely enough, you might see the filenames all lowercase in Isobuster.

About "[BOOT]" in 7-zip, other archive tools choose other names for that "folder". For example, IZArc uses "boot.images", in lowercase. Isobuster uses "Bootable Disc".

If you want / need lowercase, use a file-renamer (or a file manager with such capability). Or extract the filenames from the relevant ISO9660 extension (most probably, Joliet).

This is not just an issue with lowercase / uppercase. For example, ISO9660 will also change any character not accepted in the original standard (like "-", to "_") when building the ISO image strictly with ISO9660 only and no "extension" (like MS's Joliet). That's one reason for the ISO9660 "extensions". Would you expect from imdisk to assume or guess what was the original character in such case (which is not possible anyway)?

So, I'd suggest using the relevant appropriate tool for each task. If the tool respects the standards, much better.

#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 October 2012 - 11:55 AM

This is not just an issue with lowercase / uppercase. For example, ISO9660 will also change any character not accepted in the original standard (like "-", to "_") when building the ISO image strictly with ISO9660 only and no "extension" (like MS's Joliet).

Try pressing the same key once without pressing Shift "-" and once pressing it "_".
If you prefer, underscore IS actually the "uppercase" of "dash/minus". ;)

I don't see as "technically impossible" that the CDFS.SYS of ReactOS could be modified so that it can use the three common standards, but *something* should be added *somewhere* to allow switching between the three "modes (base/Joliet/Rockridge), something like the /X swithch of DIR, which could be easy to implement in a DIR replacement (but then again there is already ISOINFO) but an issue, I believe in Explorer and in most used file managers.


:cheers:
Wonko

#14 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 21 October 2012 - 02:51 PM

underscore IS actually the "uppercase" of "dash/minus"


What I meant was that any character other than the ones allowed in ISO9660 are replaced.

From http://en.wikipedia....me_restrictions :

All levels restrict filenames to upper case letters, digits, underscores ("_"), and a dot. Linux by default converts uppercase letters to lower case while mounting ISO filesystems.


BTW, the ISO image from Avira doesn't include Joliet. It has ISO9660 (all uppercase in Isobuster) and RR (lowercase in Isobuster). So Avira doesn't seem to be interested in facilitating extraction and manipulation of the contents of the ISO image under Windows (they don't have any reason).

Again, my humble suggestion would be to use the adequate tool for each task.

#15 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 21 October 2012 - 03:04 PM

I expected that a tool that can mount an ISO as a virtual drive (e.g. ImDisk or Virtual Clone Drive) would allow me to copy the files to a destination folder correctly.
i.e. if the ISO contains mixed-case filenames in RR format, then when I copy the files, they also should have the same mixed-case filenames.
Also, I expect that if I use a utility like 7Zip to extract the files, I will end up files that are identical to the files I copied from the virtual drive.
This is clearly not the case and it appears that I cannot trust such utilities as ImDisk and Virtual Clone Drive to deliver correct filenames in all cases.
If 7Zip, IsoBuster and linux can deliver the correct result, is it naive of me to expect ImDisk and Virtual Clone Drive to also deliver the correct result? (that's a rhetorical question, by the way!).
I don't really care what the 'standards' are or how they are interpreted - as an end user, I expect a utility to work as expected (even if the fault does lie with the MS OS!).
Olof suggested a generic RR filter driver for Windows which seems to me a long overdue utility (and I can't believe that a fix for this issue under Windows does not exist already!).
Until one is available, it seems I cannot reliable use or recommend such virtual drive utilities as Virtual Clone Drive or ImDisk to anyone in case they meet the same RR mixed-case obstruction.

P.S. In IsoBuster under the RR 'folder', the files appear as mixed case (i.e. not all lower case) - e.g. licenses\AVIRA_EULA.txt and licenses\gpl-2.txt.

#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 October 2012 - 04:18 PM

P.S. In IsoBuster under the RR 'folder', the files appear as mixed case (i.e. not all lower case) - e.g. licensesAVIRA_EULA.txt and licensesgpl-2.txt.

Heck! :frusty:
Did you actually READ what I posted? It is MiXeD CaSe in the RockRidge name!

For UNKNOWN reasons AVIRA_EULA.txt is written as AVIRA_EULA.txt (CAPITAL NAME, lower case extension) on the actual CDFS filesystem (in the Rockridge Name), so Isobuster is correct in showing it as "AVIRA_EULA.txt"....(it is WRITTEN like that)

Olof will probably love this one ;):
http://support.micro...kb/152200/en-us

Additionally it seems like the good MS guys do have provided the source for CDFS.SYS:
http://code.msdn.mic...Driver-0566e53a

:cheers:
Wonko

#17 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 21 October 2012 - 04:33 PM

@Wonko, I was referring to this quote - RR in isobuster displays mixed case, not all lowercase.

BTW, the ISO image from Avira doesn't include Joliet. It has ISO9660 (all uppercase in Isobuster) and RR (lowercase in Isobuster). So Avira doesn't seem to be interested in facilitating extraction and manipulation of the contents of the ISO image under Windows (they don't have any reason).



#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 October 2012 - 05:07 PM

@Wonko, I was referring to this quote - RR in isobuster displays mixed case, not all lowercase.

I don't get it. :unsure:
Run the ISOINFO (twice as said).
Compare results of first run with what you see "normally" in Windows/Imdisk/etc. they should correspond (apart the ;1)
Compare result of first run with what you see in Isobuster "RR" they should correspond.

At a quick glance Rockridge names are MOSTLY lower case with the exception of the mentioned "AVIRA_EULA.txt", AND of a few others, such as (examples NOT exhaustive):

Directory listing of /html/en/
dr-xr-xr-x 2 0 0 4096 Oct 20 2012 [ 26 02] .
dr-xr-xr-x 5 0 0 2048 Oct 20 2012 [ 25 02] ..
-r--r--r-- 1 0 0 10230 Oct 20 2012 [ 21753 00] favicon.ico
-r--r--r-- 1 0 0 71657 Oct 20 2012 [ 21758 00] help.png
-r--r--r-- 1 0 0 19914 Oct 20 2012 [ 21793 00] index.html
-r--r--r-- 1 0 0 3073 Oct 20 2012 [ 21803 00] kontakt.html
-r--r--r-- 1 0 0 71657 Oct 20 2012 [ 21805 00] onlineshop.png
-r--r--r-- 1 0 0 130029 Oct 20 2012 [ 21840 00] pageConfigure.png
-r--r--r-- 1 0 0 93753 Oct 20 2012 [ 21904 00] pageUpdate.png
-r--r--r-- 1 0 0 106928 Oct 20 2012 [ 21950 00] pageVirenscanner.png
-r--r--r-- 1 0 0 1443564 Oct 20 2012 [ 22003 00] pageVirenscanner_marked.png
-r--r--r-- 1 0 0 101417 Oct 20 2012 [ 22708 00] tabControlFile.png
-r--r--r-- 1 0 0 118860 Oct 20 2012 [ 22758 00] tabOtherpageAviraImpressum.png
-r--r--r-- 1 0 0 111966 Oct 20 2012 [ 22817 00] tabOtherpageFontSize.png
-r--r--r-- 1 0 0 110010 Oct 20 2012 [ 22872 00] tabOtherpageLogfile.png
-r--r--r-- 1 0 0 107709 Oct 20 2012 [ 22926 00] tabOtherpageMountProgress.png
-r--r--r-- 1 0 0 114309 Oct 20 2012 [ 22979 00] tabOtherpageNetworksettings.png
-r--r--r-- 1 0 0 162175 Oct 20 2012 [ 23035 00] tabOtherpageReadme.png

Directory listing of /html/global/
dr-xr-xr-x 2 0 0 2048 Oct 20 2012 [ 30 02] .
dr-xr-xr-x 5 0 0 2048 Oct 20 2012 [ 25 02] ..
-r-xr-xr-x 1 0 0 16357 Oct 20 2012 [ 23666 00] AVIRA_EULA.txt
-r--r--r-- 1 0 0 6991 Oct 20 2012 [ 23674 00] front.css
-r--r--r-- 1 0 0 17987 Oct 20 2012 [ 23678 00] gpl-2.txt

Directory listing of /html/images/
dr-xr-xr-x 2 0 0 4096 Oct 20 2012 [ 28 02] .
dr-xr-xr-x 5 0 0 2048 Oct 20 2012 [ 25 02] ..
-r--r--r-- 1 0 0 864329 Oct 20 2012 [ 23115 00] ARS_bootmenu.png
-r--r--r-- 1 0 0 35588 Oct 20 2012 [ 23538 00] bootscreen.png
-r--r--r-- 1 0 0 8888 Oct 20 2012 [ 23556 00] cmdline.png
-r--r--r-- 1 0 0 37444 Oct 20 2012 [ 23561 00] config_menu.png
-r--r--r-- 1 0 0 961 Oct 20 2012 [ 23580 00] de.gif
-r--r--r-- 1 0 0 283 Oct 20 2012 [ 23581 00] e3e3e3.jpg
-r--r--r-- 1 0 0 1299 Oct 20 2012 [ 23582 00] en.gif
-r--r--r-- 1 0 0 41835 Oct 20 2012 [ 23583 00] information.png
-r--r--r-- 1 0 0 3538 Oct 20 2012 [ 23604 00] logo_web.gif
-r--r--r-- 1 0 0 29037 Oct 20 2012 [ 23606 00] misc.png
-r--r--r-- 1 0 0 13273 Oct 20 2012 [ 23621 00] OLD_top_left.gif
-r--r--r-- 1 0 0 81 Oct 20 2012 [ 23628 00] red_arrow.gif
-r--r--r-- 1 0 0 36245 Oct 20 2012 [ 23629 00] scan_menu.png
-r--r--r-- 1 0 0 925 Oct 20 2012 [ 23647 00] topMenuBgd_sand.gif
-r--r--r-- 1 0 0 5902 Oct 20 2012 [ 23648 00] top_left.gif
-r--r--r-- 1 0 0 131 Oct 20 2012 [ 23651 00] top_left_dot.gif
-r--r--r-- 1 0 0 28472 Oct 20 2012 [ 23652 00] update1.png




all ISO9660 names are CAPITAL (and this is "by design").

If Isobusters resuts are different from those of ISOINFO, then there is a bug in Isobuster (rest assured that ISOINFO has never got a wrong RockRidge name).


:cheers:
Wonko

#19 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 21 October 2012 - 05:58 PM

There is nothing wrong. I was merely nit-picking that ady said that the files will appear as lowercase in isobuster, but they appear as mixed case - nothing is wrong and all is right with the world :good:
We just need to wait for Olof to supply a new cdfs.sys or filter driver which caters for RR :cheerleader: - this will ensure he is even more of a hero and will forever be remembered in the portals of time - especially as now Win8 suipports ISO mounting (but does not support RR!). Of course he could decide to make it shareware and charge a few dollars for it or even sell it to MS for including in Win 8 SP1!

#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 October 2012 - 06:43 PM

Well, when nit-picking you should be VERY accurate.

P.S. In IsoBuster under the RR 'folder', the files appear as mixed case (i.e. not all lower case) - e.g. licenses\AVIRA_EULA.txt and licenses\gpl-2.txt.

Means actually:

P.S. In IsoBuster under the RR 'folder', some of the files appear as mixed case (i.e. not all lower case) - e.g. licenses\AVIRA_EULA.txt and licenses\gpl-2.txt.


:whistling:
Spoiler



:cheers:
Wonko

#21 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 21 October 2012 - 08:26 PM

Olof will probably love this one ;):
http://support.micro...kb/152200/en-us


I clearly remember when that KB article was first published. And the discussions that followed everywhere where people used combinations of Windows and Unix in networks. They found situations where CD filesystem structures showed up somewhat different depending on whether they put the CD in a Windows machine or a *nix one. And now it is year 2012, we still have the same situation, except that very few iso images these days are actually built without Joliet namespace.

But reading that KB article again gave me another idea. Or hint, or something. Does it really say that the MS-DOS-based mscdex.exe included in Windows 95 and 98 supported Rock Ridge and the internal Windows filesystem driver did not? Or do I misread something? I feel that I need to check that under Windows 98 some time. Could be interesting to see if that actually makes any difference to anything.

#22 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 21 October 2012 - 09:01 PM

I expected that a tool that can mount an ISO as a virtual drive (e.g. ImDisk or Virtual Clone Drive) would allow me to copy the files to a destination folder correctly.
i.e. if the ISO contains mixed-case filenames in RR format, then when I copy the files, they also should have the same mixed-case filenames.
Also, I expect that if I use a utility like 7Zip to extract the files, I will end up files that are identical to the files I copied from the virtual drive.
This is clearly not the case and it appears that I cannot trust such utilities as ImDisk and Virtual Clone Drive to deliver correct filenames in all cases.
If 7Zip, IsoBuster and linux can deliver the correct result, is it naive of me to expect ImDisk and Virtual Clone Drive to also deliver the correct result? (that's a rhetorical question, by the way!).
I don't really care what the 'standards' are or how they are interpreted - as an end user, I expect a utility to work as expected (even if the fault does lie with the MS OS!).
Olof suggested a generic RR filter driver for Windows which seems to me a long overdue utility (and I can't believe that a fix for this issue under Windows does not exist already!).
Until one is available, it seems I cannot reliable use or recommend such virtual drive utilities as Virtual Clone Drive or ImDisk to anyone in case they meet the same RR mixed-case obstruction.

P.S. In IsoBuster under the RR 'folder', the files appear as mixed case (i.e. not all lower case) - e.g. licensesAVIRA_EULA.txt and licensesgpl-2.txt.


I must clarify the intention of my words.

First, the uppercase vs. lowercase. I was trying to concentrate in the ISO9660 "translation". As pointed out, ISO9660 is supposed to be all uppercase only. The other filesystems and extensions related to ISO9660 and to optical media are not limited to uppercase only. That's what I was trying to point out (but evidently not clearly enough, sorry) when I said "all uppercase" for ISO9660 and "lowercase" (not "all lowercase") for RR (the extension included in the avira ISO image). My apologies for generating more confussion about this.

Now, I'd also expect for tools like imdisk to "do the job". But imdisk (and other tools) is using what Windows gives, which is ISO9660 plus Joliet (when present). Joliet is MS's response to some of the limitations of ISO9660. In a sense, is like when users of imdisk ask why they can't see the mounted "disk" in the Windows Disk managment applet: simply because imdisk mounts a volume, not a disk.

So steve wants to copy the contents of the ISO image. Well, from which FS? I can build an ISO image with ISO9660, plus Joliet, plus RR, plus UDF. If Windows and imdisk would provide the possibility to read all of them, which FS should imdisk show you?

And what about Avira (or any other producer of ISO images)? Shouldn't they be using the standard (uppercase) and only use the extensions (RR only, in this case) when strictly needed? By not adding Joliet, they are "clearly saying" (well, this is my interpretation, so it is not really clear :) ) they don't want to put resources to make their ISO image managable under Windows. "Use Linux instead". (BTW, I think they provide other downloads for USB drives, not ISO, but I haven't tested them). Some other ISO producers have adapted their contents to respect the standards whever possible, making it more portable between OSes. Avira "seems" to respect the ISO9660 standard (I haven't check this thoroughly). Is their fault that Windows users want to use their ISO images? Is imdisk fault that Windows provides ISO9660 and Joliet? Is imdisk at fault for the ISO9660 standard (which is also compatible with DOS)?

So, my point is, should imdisk be using Windows tools (already available in standard systems) and respecting basic standards (ISO9660 and Joliet when available), or should it be assuming and guessing what each user would like to do with whichever image, even if it is not going to respect the standard?

I guess using 7-zip dll to extract the content of ISO images is not such a bad idea, if that is what you want.

Edited by ady, 21 October 2012 - 09:08 PM.


#23 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 21 October 2012 - 09:12 PM

I have limited knowledge of linux and so would like to ask these questions...

Q1. If I mounted the Avira rescue iso file under linux and then copy the file contents to my FAT32 USB pen drive, will I get all uppercase files, all lowercase files, or mixed case files the same as 7Zip delivers?
Q2. Does the user need to guess what ISO standard or extension the linux 'mount' should use when the iso is mounted?
Q3. Do you consider a linux system to be a 'standard system'?

#24 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 21 October 2012 - 09:12 PM

Something happened while I was writing my previous post, so I edit it. Please forgive me if anyone started to read it and it wasn't clear. I edit it just a couple of minutes after the initial save. Apologies.

#25 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 21 October 2012 - 09:38 PM

@steve, I think that if Linux or Windows or DOS or whichever OS is going to read ISO9660, and if the specific ISO image builder respects the standard, that is what you should see. If you want to see some "extension translation" (like Joliet, or RR), then use that. That's what Isobuster tries to do.

For example, with mkisofs (available also under Windows) you can override the limitation for only one dot in ISO9660. But if the person that builds the ISO image uses such non-standard option, can you tell me what each archive tool is going to show you (or extract or whatever)? Does it depend on the OS, or on the standard? Is _that_ important for the original file to have more than one dot in its filename? (all rhetorical questions.)

As an example, version 3.01a05 to a07 of mkisofs had some problem, generating ISO images that were not fully compliant with ECMA119. 7-zip refuses to open them, so this affected tools under Windows AND under Linux that use 7-zip code to manage ISO images. Version 3.01a08 of mkisofs solves the problem, so new ISO images (generated with the new mkisofs version) are being opened correctly with those same tools. Other tools (like IZArc) were always able to open ALL those ISO images.

So it is not about a specific OS. There is a reason for standards.

IF imdisk could open different FS available in a certain ISO image, would every user be willing to learn about all these available FS so to decide each time which FS to read and open?

You CAN trust imdisk, because it uses the available standards under Windows. The problem is that, apparently, for your final goal (whichever it is), imdisk is not the most adequate tool in this particular case.

I'm not sure how exactly to solve the problem. But I know that if there is a certain technical standard (ISO9660, Joliet, RR, UDF), it is generally better (for the final user) to respect it by all ("all", or as many parties as possible), than to "guess" what the user wants.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users