Talk:Joliet (file system)

Merge

Should merge with ISO 9660 — Claunia 22:56, 25 August 2005 (UTC)

Are there patents covering the the Joliet ISO 9660 Extension?

Does somebody know if FAT-Joliet patents applies also for ISO 9660-Joliet? faragon 0:52, 12 April 2009 (UTC+2)

Seems that it is covered US Patent 5758352 - Common name space for long and short filenames, so some trick has to be done in order to avoid the patent. 1:03, 12 April 2009 (UTC+2) —Preceding unsigned comment added by Faragon (talk • contribs)

That patent doesn't cover Joliet in general, as Joliet doesn't specify anything except what is done inside the context of the supplementary volume descriptor, as far as I can see. But if you create a Joliet CD, it has to have a Primary Volkume Descriptor, which means that the long file names in the Joliet section need to be transformed into shorter file name, and in a way that doesn't cause name collisions. The patent cited covers one (or more) methods for doing that.Athulin (talk) 07:27, 25 May 2010 (UTC)

(file system) vs. (ISO 9660 Extension)

Joliet (ISO 9660 Extension) redirects to Joliet (file system) - I'm going to swap these around, as (file system) is inaccurate, afaik: Joliet is not a self-contained file system. '(ISO 9660 Extension)' seems a good extension to settle on (see Category:ISO_9660_extensions). I'm just announcing ahead of time incase there are objections. -- Jon Dowland 14:03, 11 March 2006 (UTC)

I think it is better to merge, but, it is a step.—Claunia 14:58, 11 March 2006 (UTC)

Most disc creation software creates...

I don't think it's accurate to say "Most disc-creation software creates both Joliet and Rock Ridge extensions on the disc". Common Microsoft Windows based disc-creation software just creates standard ISO9660 and Joliet.

Agreed (neither Nero nor EZ CD Creator, both for Windows, nor Toast nor Apple's CD creation API, both for Mac OS, do this). I'll change that. -- Tempel 07:21, 12 October 2006 (UTC)

What happened to the Romeo filesystem?

Does anyone knows what happened to the Romeo Filesystem? At the time of Windows NT 4.0 and Windows 95/98, Romeo was he filesystem of choice to record files with names of 128 characters. However, I have noticed that not only Romeo has disappeared, but newer version of recording softwares (such as Nero) supports Joliet filesystems with filenames longer than 64 char long (the originaly supported). --Pinnecco 23:46, 10 July 2006 (UTC)

Romeo broke the backward compatibility to DOS and other systems as it didn't contain ISO 9660 file system. Joilet is the combination of Romeo and ISO 9660 and cutting the file name space in half from 128 to 64 chars to save the place for ISO 9660.--80.171.118.114 (talk) 19:17, 25 December 2007 (UTC)

That information is wrong. ISO9660 allows for several list of files, the primary plus several secondary or extended ones. On the primary it clearly specifies a limit of 30 characters (ISO level 2, there is a level 1 that limits the filename to 8.3 characters) in a range that is mostly only caps and numbers. On the secondaries it allows any codepage that has an ISO escape code and filenames, with the same filename size limit (that would be 30 bytes in most codepages and a maximum of 60 bytes on some codepages, like chinese ones), while on the extended ones the limit is upped to 207 bytes.

Romeo uses a codepage in the primary list of files, without specifying which one, and allowing longer filenames. This is more a side effect of how invalid data in the ISO9660 structures is handled. DOS and other operating systems reserve a certain size to the filename they expect to read, so DOS will only see 8.3 filenames (ISO level 1) and Mac OS 9 and earlier will see up to 31 characters (one more than ISO level 2). They will also expect the codepage to be ASCII. Windows NT driver however, will read the whole filename (that is maximum 207 bytes) and use the current user codepage to convert it to the internal UCS-2 representation. . Allowing this behavior, instead of enforcing ISO9660 restrictions, is basically Romeo.

Joliet on the other hand, uses a secondary list of files with the UCS-2 encoding with a file name limit of 128 bytes (instead of the 30 characters defined by ISO9660). They did this instead of using an extended list of files, because extended lists where not defined in ISO9660 by the time they created Joliet.

In any case, both Romeo and Joliet violate the ISO9660 specification, and both could be implemented using ISO9660 provided structures as a conformant extension, but they were not done so, one because "it was already there" and the other because it could not be so as it predates the allowances.

Also the thing is that while technically you can have a fully compliant ISO9660 disc that contains filenames in 8.3 ASCII, plus 30 Cyrillic characters, plus 128 chinese characters, there is no software that allows you to create such a disc, neither it is supported by any implementation I know of (I would need to handcraft one such disc myself to test, as said, no software can create it, but neither Linux or Windows available source code show it would work). However, it will work on any implementation, even DOS, because the primary list of files conforms to ISO Level 1 (8.3 ASCII), and it will just ignore the secondary and extended lists. Again, Romeo is incompatible with some OSes because it uses the primary list with incorrect data.

Claunia (talk) 14:04, 23 July 2019 (UTC)

Naming?

Why is it called Joliet? —Preceding unsigned comment added by 96.241.212.160 (talk) 08:47, 5 March 2009 (UTC)

In case someone still wants to know: It's because first someone "invented" the "Romeo" extension to ISO 9660. Don't remember the full story on that one any more, though. Maybe Google will help to lighten up this mystery. Tempel (talk) 00:18, 17 September 2010 (UTC)

The Joliet.doc file, present in the Microsoft Windows 95 DDK, does not contain any obvious information as to the origin of the name. In the file metadata, however, there is a comment, saying "Joliet is a small town just outside of Chicago, where a man named Jake did some time in The Blues Brothers." Athulin (talk) 17:36, 18 May 2011 (UTC)

I downloaded the Windows 95 DDK (http://old-dos.ru/index.php?page=files&mode=files&do=show&id=3274) to check this and could not find any Joliet.doc file. 68.61.156.5 (talk) 02:24, 15 October 2017 (UTC)

Hm, it looks as if there may be multiple releases of this. The CD I checked is a Microsoft Developer Network CD, from the 'Development Platform' group, issued in January 96. Its label says "DDK: Windows® 95 DDK" / DISC 8. It has the JOLIET.DOC file in the \DOCS directory, dated 1995-05-12 (which is a bit odd, as the title page of the document itself says "Version 1 / May 22, 1995"; also, the Word document internal last-modified-date is 1995-05-09; its author is Rick DeWitt.)

The DDK you cite looks like it may a later release, with changes and updates: root-level directories are dated 1998, not 1995, as in my copy. Athulin (talk) 09:40, 24 July 2020 (UTC)

Article needs name information

The origin of the name should really be covered by the article. The article is not complete without this explanation. If the above statement can be sourced, please add it to the article. --Wykypydya (talk) 05:44, 7 July 2011 (UTC)

Joliet: extension or not?

I have updated this section, as I did a deep-dive into Joliet (as contained in http://www-plateau.cs.berkeley.edu/people/chaffee/jolspec.html or http://www.buildorbuy.net/pdf/joliet.pdf) and ISO 9660:1988.

Here's what I found:

• Joliet does not extend ISO 9660 to cover wide characters.

ISO 9660 is clear that supplementary volume descriptors may contain character set specifications through ISO-2022 mechanisms, as registered by the ISO in International Register of Coded Character Sets (http://www.itscj.ipsj.or.jp/ISO-IR/). And as this registry covers UCS-2 (which is what Joliet uses) as well as UCS-4 character sets, and also UTF-8 and UTF-16, ISO 9660 actually allows wider character sets than Joliet does.

Joliet does make it clear how the chosen character set (UCS-2) should be recorded (most significant byte first). I think ISO 10646 says this already, but it's useful to have it stated directly.

• Joliet changes the rules for directory name construction (ISO 9660 section 9.1.11: Joliet allows '.' to be used in directory names.)

• Joliet changes the rules for how the order of entries in path tables and directories is decided. In ISO 9660, field of unequal length are padded with space (with file version number, the character '0' is used) to make the entries equally long before they ar compared byte by byte. Joliet specifies that the pad character should be (00). This affects file and directory names that have trailing spaces, and, if Joliet permits file version numbers (which it is not clear if it does), it also affects the order of entries such as 'AAA.BBB;1' and 'AAA.BBB;10', which in ISO 9660 is unspecified (as appending a '0' to the shorter makes them equal).

• Joliet does extend ISO 9660 as regards file/directory name length (31 -> 128) and directory hierarchy depth (8 to no stated limit -- but can be at most 120).

• Joliet adds a restriction to ISO 9660 in terms of maximum permitted file path length (from 255 to 240).

• Joliet adds a restriction to ISO 9660 to entirely exclude the characters '*/:;?\' from permitted characters.

I suspect the idea must have been to exclude those characters from the characters permitted in file names (i.e. the d1 character set in ISO 9660), but the way it is expressed it seems to limit the full a1 character set as well. And as ';' = SEPARATOR 2, required in 9.1.11, this affects the interpretation of file name versions in a way that is not clear. And also, as Joliet has not defined the a1 and d1 character sets appropriately, there is a general unclarity in this area.

It should be noted that I'm still a bit unsure about the length extensions: Joliet is clear that it measures length in bytes, but ISO 9660 is not quite as clear if it is bytes or characters.

Thus, I don't think it is correct to say that Joliet is an extension of ISO-9660. It extends it in some areas, and restricts it in others.

Athulin (talk) 08:37, 4 May 2010 (UTC)Athulin (talk) 08:54, 13 June 2011 (UTC) .

It is not uncommon to talk of any follow-on specification which modifies an earlier standard as "extending" it, even if there are some tighter restrictions. I don't see any value in debating the semantics of "extension" here.  :-) If it bothers anyone, I'd suggest changing the article to use words like "modification", "change", etc. —DragonHawk (talk|hist) 17:16, 29 May 2012 (UTC)