Talk:ISO 9660/Archive 2

Archive 1

Archive 2

Limit on number of directories

I'm not sure I agree with the article, which states that there is a limit on the number of directories, imposed by the restriction of the field 'Parent Directory Number' (9.4.4) to 16 bits. The reasoning seems to be that if a directory produces a path table entry that (in theory) would get a Directory Number (though never explicitly recorded) > 65535, it is not permitted to exist.

Main objection: There is no explicit limit of the number of entries in the Path Table, only that the Path Table can't exceed 2^32-1 bytes. This appears to allow any number of entries as long as their *Parent Directory* Number fits in the 16-bit limit. That is, as long as the number of directories in level 1..7 don't exceed 65535, one additional level of directories can be accommodated without breaking either the word or the data structures of the standard.

Additionally, a Path Table is expected to contain entries also 'for those volumes of the Volume Set the sequence numbers of which are less than, or equal to, the assigned Volume Set size of the volume.' That is, the Path Table is expected to cover multiple volumes. It could be very awkward for a publisher to publish monthly volumes of an annual volume set, and find in October or so that the path table is full, and that no new directories may be created in that Volume Set.

A possible interpretation is that the Path Table is an auxiliary structure, intended to speed up access to directories that fit within it, but the reader application must always be prepared to fall back to normal file tree walking when a directory is not found in the Path Table. As the file tree must cover also earlier volumes in the set, all paths within that volume would be resolvable by referring to the last volume only, even if actual access might require changing to an earlier volume CD-ROM. The objection to this is that the standard text does not say so, either. Chapter 12 would have been the right place to allow for the data preparer to select path table contents, but I find nothing like that.

I suggest dropping this section altogether, as I think it overstates the situation. Or am I missing anything?Athulin (talk) 12:07, 30 December 2015 (UTC)

Given that there is at least one implementation that fails without a path table (DOS), your wish does not look helpful. Schily (talk) 14:08, 30 December 2015 (UTC)

I don't see the relevancy of that. I'm not saying that path tables can be omitted, I'm saying that there's no clear ground for saying that the 16-bit size of Parent Directory Number is an implicit restriction on the number of directories allowed within a Volume Set.Athulin (talk) 10:09, 1 January 2016 (UTC)

Misunderstanding of the Standard?

Is that something that should be included? I'm thinking of the 8+3 file name restriction that far too many people say is a restriction in ISO 9660, when it's either a restriction selected by a CD-ROM publisher, or a failure of an implementation to implement the standard correctly. I think 2.1 makes that clear: 'Level of Interchange' is something that applies to a CD-ROM, not to a subset of the standard. — Preceding unsigned comment added by Athulin (talk • contribs) 10:16, 1 January 2016 (UTC)

ECMA-119 vs. ISO 9660

The note "this standard is identical to ISO 9660 (but please be careful because it has several small incompatibilities with real-life iso images)" for ECMA-119 lacks proof or reference. What are the actual differences? I don't think there are any because the 2nd edition of ECMA-119 states that it is "technically identical with ISO 9660" (see Brief History). — Preceding unsigned comment added by 84.176.238.81 (talk • contribs) 20:39, 26 October 2006 (UTC)

I agree. Unless someone can quote differences that we can verify, this unspecific warning is no help to anyone. -- Tempel 19:09, 12 November 2006 (UTC)

Here's a minor one. In section 8.5, the table over the fields in a Supplementary Volume Descriptor contains some significant techical differences. ECMA-119 specifies several fields as 'a-characters' or 'd-characters' or 'd-characters, SEPARATOR 1, SEPARATOR 2', while ISO 9660 specifies these fields as using a1-characters or d1-characters correspondingly.

The text descriptions of the fields do specify 'a1' and 'd1', but someone who didn't double-check things might go with the table. -- Athulin (talk) 10:13, 1 July 2014 (UTC)

A major difference is, of course, the changes introduced in ISO 9660 Amendment 1 in 2013. The claim of 'technical identity' in ECMA-119 is therefore no longer correct. (Though it must be admitted it is a bit of a chore to refer to ISO 9660:1988/Amd.1:2013 to refer to the latest text.) Athulin (talk) 09:35, 28 December 2014 (UTC)

That difference has since disappeared, as ECMA-119 has been issued in a later version (rev. 3), covering also the Amendment 1 changes. If there remain any technical differences (except such minor differences that ISO refers to the ISO character code standards and ECMA refers to ECMAs code standards) they are almost certainly unintentional. Athulin (talk) 18:41, 27 October 2019 (UTC)