[EMAIL PROTECTED] (James Pearson) quoted and then wrote: >>I found a CD that looks a bit strange. >> >>Is there anybody who really knows Joliet and can help? >> >>The SVD of the CD contains escape sequences that I would call buggy: >> >>The first bytes are: 0: '%' 1: '/' 2: 'E' 3: ' ' > >Certainly looks like a bad escape sequence - for UCS-2 Level 3 it should be: > >%\E
Quoting precisely from my copy of of the Joliet specification (consistent between several web sources): UCS-2 Level 3 2/5, 2/15, 4/5 (25) (2F) (45) '%\E' That last item, the backslash in particular, disagrees with the 2/15 and (2F) representations, which would make it slash. ISO 646 (as shown, for instance, in Annex A of ISO 9660 : 1988 (E)) indicates a backslash would be 5/12 or (5C), which is not a legal Intermediate Byte of an escape sequence according to 13.1 of ISO/IEC 2022:1994(E). >>and from esc[3] .. esc[31] all characters are spaces instead of nuls. >> >> Mkisofs uses nuls. > >As the Joliet spec states that the escape sequences conform to the ISO9660 >standard for the Supplementary Volume Descriptor (section 8.5.6), then the >remaining bytes should be nulls. > >>In addition, the Joliet repesentations of the filenames look strange: >> >>d--------- 0 0 0 2048 Feb 5 2002 [ 420] . >>d--------- 0 0 0 8192 Feb 5 2002 [ 344] .. >>---------- 0 0 0 4304 Dec 20 2001 [ 159908] ipc.h.html;1 >>---------- 0 0 0 136 Dec 12 2001 [ 159907] list.;1 >... >> >> Mkisofs never adds ';1' to joliet filenames. > >I had an email exchange with Eric about this when he first added Joliet >to mkisofs - the Joliet spec (which is written as if it were an addition >to the ISO9660 standard) states that: > >"Simply put, SEPARATOR 1 and SEPARATOR 2 shall be expanded to 16-bits". > >SEPARATOR 2 is ';' - which is used signify the version number of a file. > >So, the Joliet spec allows for file version numbers, but as Eric was >implementing Joliet using Joliet CDs he had available - which didn't have >version numbers, he decided to leave off the version number. I would say that by not changing the wording of ISO 9660 in this regard, the Joliet specification _requires_ version numbers. A close reading of ISO 9660 13.3.2 in the last bullet list shows no requirement for a Receiving System to make available to the user the File Version Number, so it may be that typical Windows machines do not display that, but it still should be present on a Joliet disk. (On Macintosh, the file version number is also hidden, unless one mounts the disk in a special manner.) >So theoretically, having version numbers follows the Joliet spec, so >mkisofs is doing it wrong, but as all (??) Joliet readers seem to ignore >whether there are version numbers or not, I don't think this is a problem. > >However, having an incorrect escape sequence doesn't follow the Joliet spec >or the ISO9660 standard. Likewise, the lack of version numbers (apparently, based on these reports) has not caused a problem. So why should one care about one part of the standard and not another ? The general rule is to be liberal in what you accept and conservative in what you generate, which would mean generating version numbers and nulls padding the escape fields in all cases. ================= Another Joliet interpretation that I see as wrong is the tendency to fill Volume Descriptor character fields with nulls rather than (UCS-2) spaces. I can find no excuse for this behavior in the Joliet specification, but I find lots of CDROMs filling with (00)(00)(00)(00) etc. rather than with (00)(20)(00)(20). The Joliet specification specifies use of (00) as the sort justification pad byte, but that does not apply to fields of the Volume Descriptor. Larry Kilgallen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
