Talk:ISO 9660/Archive 1

Archive 1

Archive 2

Clarification on "dump utility"

Can someone clarify ...

"When checking CD-ROMs with a dump utility we find each descriptor back in a single logical sector on itself, and also a backup of the descriptor a few logical sectors further."

I can't work out what it's saying - sorry :-(

SDS 02:55, 3 March 2006 (UTC)

I believe it refers to the sentence before it, which suggests that there is a backup of the VRS and how to locate it. Basically, what wants to be said is that each descriptor is stored in a separate sector (meaning that if one has a bad bit, the other sectors might not be affected) and one can try to locate its backup in such a case. So, it tries to explain what could be done in case of a read problem in regards to recovery.

Tempel 14:40, 13 March 2006 (UTC)

UDF on DVDs

While all DVD-Videos have to have UDF, when it comes to data DVDs, I have seen many which either only have ISO9660 or have both. Therefore, I would suggest it is incorrect to state UDF is much more common on DVDs. Indeed, I don't know if I've come across any non DVD-Video with only UDF (whereas, as I've said, I've come across many with only ISO 9660). So I have modified the comment which suggests UDF was far more common on DVDs. Nil Einne 13:05, 13 June 2006 (UTC)

Other file systems than ISO 9660?

The article currently makes the claim that Sun, Apple, and Silicon Graphics write CD-ROMs using their native file systems. For Sun, this is true for some distribution volumes but not for any disc mastered bythe user; one simply uses mkisofs to make an image of the CD-ROM and then burns that image with cdrw or your favorite burner software. For Macs, if one uses drag-and-drop creation of the CD-ROM, one gets ISO-9660. (And I don't know about SGI.)

Should we delete the "not ISO" claim from the article?

Atlant 17:16, 17 February 2006 (UTC)

I was under the impression that macs burnt a hybrid format which had hfs+ structures for the MAC (so things like mac apps would work off them) but also ISO-9660 structures so that data files on the CD could be read by other operating systems. Plugwash 17:20, 17 February 2006 (UTC)

'Pretty sure Macs burn the extra Finder information as ordinary, slightly-hidden files on the ISO-9660 structure, much like they do for PCFS-structured disks. But I'm only "pretty sure".

Atlant 17:31, 17 February 2006 (UTC)

You are fully wrong.

Before MacOS X, Apple added extensions to ISO9660 to store icon location, long names and Finder attributes. However this extensions don't store the resource fork (essential for most files in a pre-Mac OS X enviroment). I have yet not seen any mastered disk or any utility to create disks (except mkisofs) with these extensions.

All mastered disks by Apple are HFS, generally with partition map and CD drivers, however this is optional.

MacOS X disks and later use HFS+, and the included support for burning disks create an hybrid HFS+/ISO disk.

NeXTStep and OpenStep treats CDs and floppies like hard disks, and use UFS with a NeXT partition map.

Rhapsody for PowerPC disks use an Apple Partition Map with a HFS partition (the installer) and a partition containing a NeXT partition map and a UFS partition (the system).

IRIX installation disk not only aren't ISO9660 but also don't use 2048 byte sector, but 512 byte sector requiring special writes and sometimes even special readers.

—Claunia 21:01, 17 February 2006 (UTC)

OK, here's some info from someone who has written applications for both creating and reading ISO and other Mac specific formats (as in "joliet volume access" and "Toast") (Hi Claunia, nice to see you here getting involved :)

1. The tech note "FL-36" (http://developer.apple.com/technotes/fl/fl_36.html) explains the extensions apple made to ISO-9660 in order to store most of the HFS volume's properties on ISO discs. This _includes_ resource forks. The Mac software Toast is the most prominent program to create such disks. (so, here Claunia is wrong)

2. Apple used to and still does create CDs and DVDs with only a HFS (or HFS+) volume format on them. That's usually the case when the disc only contains macintosh specific data, such as a bootable DVD to install Mac OS from.

3. When using Toast or Apple's own disk recording software, usually the CDs/DVDs get written in the hybrid format which contains the files only once, while containing both a ISO-9660 (which in turn might contain both a Level1 and a Joliet directory) and a HFS (or HFS+) directory.

4. The presence of HFS(+) is usually detected by finding a "MDB" (master directory block) in the 3rd 512 byte block of a volume, meaning it would be located at offset $1000 in the first CD sector. Note that this does NOT necessarily mean that there is a Mac compatible partition table. Instead, you just find the CD to contain one whole Mac partition without a table. But it is also possible to have a Mac partition table - this is necessary in order to add boot code that allows a CD/DVD to start up a Mac - in this case the 3rd 512 byte block contains a PD descriptor instead, IIRC.

Tempel 14:29, 13 March 2006 (UTC)

Can someone who understands all this provide a simple summary of this for newbies (like me), eg 'If you burn a CD on a Mac using Toast it will be in ISO 9660 format'. Or is it the case that any modern OS/software will normally use ISO9660? It's very hard for me to determine if this is the case from the text and comments so far. Thanks!!! 83.217.105.178 17:20, 1 December 2006 (UTC)

See also: turning into a link repository

Do we really need ALL these links to software? vmz 02:32, 8 March 2007 (UTC)

Sources!

I've tagged this article with {{Refimprove}} because it has almost no sourcing, and many sections read like they have a significant amount of original research. Remember: if it's in an article, it needs to be attributable to a verifiable, reliable source. I'll do what I can to add some sources, but I will be ruthless with unsourced material that reads like original research. Cheers. —GrimRevenant 09:15, 20 June 2007 (UTC)

The only sources are (1) the EMCA or ISO standard, which is not available on the net but only in printed form for quite some money. I have this printed docs and while I could add page numbers to many of the things explained here, it's still not verifyable as you'll not have a way to look at the standard unless you order it from ECMA. Why not stop questioning these things, which are pretty common knowledge to anyone actually writing software for these. If you want to question something, please FIRST show why that what's claimed here is suspicious to be wrong. Then we'll see, OK? For instance, I've written in the 4GiB section that I've done empirical tests. And then I explain the workings behind it, which means that both the theory and the result match. Unless you can prove me wrong, please don't make it unnecesarily hard.

Tempel 19:57, 6 October 2007 (UTC)

Removal of "Version number" section

I've removed this entire section today from the main article:

===Version number===

According to the standard, a version number in the format ";1" must be appended to each file name. However, this may cause problems in some situations.

I've removed it because the information is vague and has no useful information in it. Well, yes, it explains that the version number must be present, but then there are many more little details that are in the spec and not mentioned here. This article is about explaining what the format means to the user, not to a driver implementor. And to the user this is of no importance (well, yes, there may be file system drivers that do not deal with version numbers correctly, but that would be a bug in that driver, not something for this section).

Tempel 20:04, 6 October 2007 (UTC)

Better specifications, please

These have many gaps. I think they must be replaced with complete specs. --87.122.10.198 22:50, 3 August 2007 (UTC)

The complete specs can be ordered in print from ECMA. But since they're copyrighted, we can't simply post them on the web. Does that answer your question?

Tempel 20:00, 6 October 2007 (UTC)

I am surprised to notice that the ECMA standard is now available as a PDF to everyone. This makes it much easier now to add references. This also means we can remove the pandora and other links from the "External links" section. Tempel (talk) 19:13, 25 November 2007 (UTC)

Info on ISOVFY

http://www.fifi.org/cgi-bin/man2html/usr/share/man/man8/isovfy.8.gz It says it's a GZ file but the browser is supposed to view it as HTML. No, I didn't make that (bad IMHO) decision to use .gz.

It should probably be changed to say 'isovfy [6]' where the 6 leads to a link at the end of the article. There's no reason to create a stub article just for one utility in a set. ISOInfo would make more sense to refer to as a link to a manpage site. JWhiteheadcc (talk) 15:03, 12 January 2008 (UTC)

Nero bug reference vague ?

The article says : "Nero Burning ROM (Windows) doesn't check if the problem occurs, and produces an invalid ISO file or disk without warning."

That is very vague. Up to today there were like 100 releases of Nero, in different packages. Which have this problem ? Which not ? --Xerces8 (talk) 13:34, 13 January 2008 (UTC)

I'd say that you need to contact Ahead's support and get them to find when/if this bug was fixed. The history file in the program directory might list this. http://www.nero.com/enu/support-contact.html

BTW: Searching for "path table overflow" nero on google leads to an embarrassing situation. Plagorism alert!  ;) JWhiteheadcc (talk) 15:50, 16 January 2008 (UTC)

Joliet: extension or not?

In some places in the text, Joliet is mentioned as an extension to ISO 9660. This is somewhat confusing, and may need to be expanded upon. (It might be a consequence of the Joliet article, which I believe is wrong on this point.)

If I take the ECMA-119, and examine the description of the Supplementary Volume Descriptor, I find that character coding conventions for strings 'inside' this Descriptor and the structures it references must be registered through ISO-2022. The three (?) escape sequences identified by the Joliet specification are indeed registered in this way. (See http://www.itscj.ipsj.or.jp/ISO-IR/, last entry: Coding systems different from that of ISO/IEC 2022: Coding without standard return)

The Microsoft KB on the subject (http://support.microsoft.com/kb/125630) suggests very strongly that Joliet (at least now) is ISO-9660 compliant, and that the only thing Joliet adds is clarification of ambiguities. I haven't examined each point in detail, so I may be too optimistic here. (Added: Yes, I was. Joliet actually changes rules, not just maximum lengths and similar arbitrary limits.)

It's interesting to note that one of the codings that ISO-2022 has registered (see ) is UTF-8 (I count four registrations in all), and that thus ISO-9660 supports wide characters even without the Joliet add-on.

I have updated the talk entry in the Joliet article accordingly.

Athulin (talk) 08:55, 4 May 2010 (UTC)

What is the ISO-9660 format also known as?

What is the two other names of the ISO-9660 format? Kagemaru the Ninja of the Shadows (talk) 18:05, 5 December 2008 (UTC)--Kagemaru the Ninja of the Shadows (talk) 18:05, 5 December 2008 (UTC)

One is Red Book

JWhiteheadcc (talk) 20:12, 21 December 2009 (UTC)

What? What Red Book is referenced? The Philips Red Book specifies audio CD (i.e. CD-DA), which has nothing to do with ISO-9660.Athulin (talk) 07:15, 10 April 2010 (UTC)

It is Yellow book that evolved via a few revisions into ISO 9660. 109.153.242.10 (talk) 18:18, 30 December 2011 (UTC)

The Yellow Book specifies the CD-ROM format: physical format, material, mechanical characteristics, the layout of sectors of a digital data track, etc. This is the format inside which the ISO-9660 format usually exists: they should not be confused. You can see most of what the Yellow Book standard contains in ECMA 130, which can be downloaded for free. The Yellow Book has roughly the same relation to ISO-9660 as X3.171/ISO 8860/ECMA 100 floppy disk standard has to the FAT12 file system.Athulin (talk) 17:10, 18 February 2012 (UTC)

Multitrack

Point 2 under the Disc Images section claims that ISOs may be multitrack with a TOC. This is counter to what is said in the main article for ISO image, and it also seems that way in practice, for example Alcohol 120% will not write to an ISO if the source disc is multitrack. Can someone clarify please. Ham Pastrami (talk) 10:22, 18 March 2010 (UTC)

Looks wrong to me. But I do occasionally see the term 'ISO image' being used not to identify the image type described the that wiki article, but a CD-R image in general. For example, some people call a Clone CD image for 'ISO image'. That may explain the abuse of the term, though it should not be taken as an indication of general acceptance. I'm tidiying it up a little ...Athulin (talk) 17:35, 18 February 2012 (UTC)

Plagiarism question

Isn't a lot of this article plagiarized from http://users.pandora.be/it3.consultants.bvba/handouts/ISO9960.html? Goffrie 01:45, 5 May 2006 (UTC)

I have only had a quick look at the mentioned article, and I found a few similar sentences, such as the phrases "... shall mean that the Volume Descriptor is a ...", but those rather sound like phrases from the original ISO 9660 documented and copied by both the mentioned article and this wikipedia article. Does someone have the ISO standard at hand and can confirm this? Are there other possible plagiarized parts from the mentioned article that do not appear in the ISO 9660 standard? --Tempel 17:26, 26 September 2006 (UTC)

There were several paragraphs copied directly from that webpage, which were not verbatim from the standard. I tried to reword those parts as best as I could, to keep the useful content.Sega381 (talk) 16:21, 1 May 2013 (UTC)

ending descriptor?

The text says an ending descriptor is "a variable length table that contains information on how many other descriptors are present". I cannot find any reference to something like this within ECMA-119. As far as I understand it, there is nothing within the Volume Descriptor Sequence that tells how many Volume Descriptors there are.

I agree. That quote is just nonsense. I'll see if I can rewrite that. Tempel 11:02, 13 November 2006 (UTC)

This was also copied form the reference above (http://users.pandora.be/it3.consultants.bvba/handouts/ISO9960.html), so apart from confusing, it was also a copy-paste from another source. Sega381 (talk) 16:25, 1 May 2013 (UTC)

Incorrect info

I'm pretty sure the following is partially incorrect. For starters, CDDA is not mode 2. Also, it fails to discuss the difference between mode 2 form 1 and form 2. I'm pretty sure all this is discussed elsewhere and it isn't really relevant to ISO 9660 since that's just a file system. It would be best just removed IMHO.

CD-ROM Specifications

The smallest entity in the CD format is called a frame, and holds 24 bytes. Data in a CD-ROM is organized in frames and sectors. A CD-ROM sector contains 98 frames, and holds 2352 bytes.

CD-ROM Mode 1, usually used for computer data, divides the 2352 byte data area defined by the Red Book standards into 12 bytes of synchronisation information, 4 bytes of header data, 2048 bytes of user data and 288 bytes of error correction and detection codes. These codes help prevent the data from becoming corrupted, which could lead to errors for executable data.

CD-ROM Mode 2, usually used for audio/video data, divides the 2352 bytes into 12 bytes of synchronisation information, 4 bytes of header data and 2336 bytes of user data. The main advantage of Mode 2 is that it provides an additional 14 per cent of user data space, since it does not have the additional EDC and ECC error correction data provided by Mode 1. This is unnecessary, since a read error will only cause a small error in this type of data.

Nil Einne 13:14, 13 June 2006 (UTC)

This belonged to the CD-ROM article, and in fact was kinda already there. I condensed this section to explain only the relation between the modes and the ISO 9660 file system, and moved whatever wasn't alread in the CD-ROM article over there. Sega381 (talk) 16:28, 1 May 2013 (UTC)

Also note, according to the mkisofs man page the ISO standard allows filenames to be up to 31 characters long without any extensions such as Joliet or Rockridge. This is not recommended as disks with this format cannot be read by operating systems limited to 8.3 filename formats (read DOS). I have however found this necessary to allow large numbers of files with similar filenames which cannot be munged into enough combinations to fit the 8.3 format. —Preceding unsigned comment added by 173.22.132.165 (talk) 15:47, 11 March 2009 (UTC)

ISO9660:1999

Could someone who knows this stuff please post some info on ISO9660:1999 (also called Level 4)? I'd be especially interested in compatibility stuff (is it backwards compatible? Can I use it with Joliet for Unicode CD-ROMs? Or does ISO9660:1999 support Unicode itself?) Thanks --Michael

Consider this a "me too" reply to the above. The following is from the man page of mkisofs, but I don't know if it's canonical ISO9660:1999 information or not:

Level 4 officially does not exists but mkisofs maps it to ISO-9660:1999 which is ISO-9660 version 2.

With level 4, an enhanced volume descriptor with version number and file structure version number set to 2 is emitted. There may be more than 8 levels of directory nesting, there is no need for a file to contain a dot and the dot has no more special meaning, file names do not have version numbers, the maximum length for files and directory is raised to 207. If Rock Ridge is used, the maximum ISO-9660 name length is reduced to 197.

When creating Version 2 images, mkisofs emits an enhanced volume descriptor which looks similar to a primary volume descriptor but is slightly different. Be careful not to use broken software to make ISO-9660 images bootable by assuming a second PVD copy and patching this putative PVD copy into an El Torito VD.

FWIW, level 4 seems to allow longish file names, preserve case, and accept Rock Ridge and Joliet extensions.

--68.41.122.213 17:06, 1 December 2005 (UTC)

The changes introduced by ISO 9660:1999 to ISO 9660 are tied to the introduction of the enhanced volume descriptor. The enhanced volume descriptor is similar to the primary and supplementary volume descriptors in ISO 9660.

Source code to the Windows XP and Windows Vista CD file system drivers is available in the Windows Vista WDK from Microsoft. Examination of this source code indicates no support for the enhanced volume descriptor.

Examination of the Linux 2.6.25 kernel sources indicate no support for the enhanced volume descriptor.

Empirical tests with Windows Vista and current versions (as of 2008.04) of the utility applications IsoBuster, PowerIso, MagicIso, and UltraISO, indicate no support for the enhanced volume descriptor.

Many systems and applications, including those mentioned above, are able to read ISO 9660:1999 media through the primary volume descriptor and handle the various introduced relaxed restrictions on file name length and directory depth.

The text in the online ISO 9660:1999 document indicate "Japanese National Body submitted its English text to JTC1 for approval under a fast track procedure." but do not indicate its acceptance. ISO 9660:1999 has not been adopted as a standard by ISO or ECMA.

Jlaw7 (talk) 00:28, 26 April 2008 (UTC)

This entry title is misleading. According to the current ISO catalogue of standards, there is no such thing as ISO 9660:1999. Remaining possibilities are: a withdrawn standard (but it does not appear in that listing either), or a draft standard (in which case, it should be not referenced as a ratified standard). There seems to be a related Japanese standard (JIS X 0606:1998), but as there doesn't even seem to be an ISO/DIS 9660, it must be an a very early stage of standardization still, if it even is under ISO consideration as a full standard. Athulin (talk) 08:25, 15 May 2011 (UTC)

Apart from the document describing that potential ISO9660:1999 / JIS X 0606:1998 (http://www.pismotechnic.com/cfs/iso9660-1999.html), the only reference I can find about it is in this FAQ page]. Any other reference is either a copy of the information in this Wikipedia article, or questions about tools that claim to support this. It seems to me that several tools refer to this ISO 9660:1999 "mode" when they want to allow longer file names, since operating systems are able to read longer filenamse anyway, even if that feature is not in a published standard. I will try to reflect this in the article. Sega381 (talk) 16:43, 1 May 2013 (UTC)

Copyvio?

Some of the content seems to be copied from [1] In particular, part of the ISO 9660 Specifications section. 193.152.203.66 (talk) 11:15, 1 August 2008 (UTC)

Yes, I tried to fix this as per the discussion in this section above. Sega381 (talk) 17:10, 1 May 2013 (UTC)

ISO-9660:1988/Amd.1:2013(E)

ISO published a major amendment to ISO-9660 in May, 2013. From a quick read-though of appendix B I see that they introduce a new volume descriptor (Enhanced Volume Descriptor) , which leads to a number of changes for file trees rooted in an Enhanced Volume Descriptor: new Volume Descriptor Version and File Structure Version, limit of file hierarchy removed, file names are no longer split into file identifiers, file extensions and version number, and file and directory names are allowed to be 207 characters long.

There are also changes coming from the Joliet Specification, but it takes deeper analysis to see if they are related to the Enhanced Volume Descriptor only, or if they stand on their own. The document is essentially only 'patch instructions' to the original standard.Athulin (talk) 16:34, 6 June 2014 (UTC)

2GB limits

Funny how I'm defending a rather small edit, but I felt like raising a small point that hopefully illustrates some issues =)

I removed this bit from ISO 9660#The 2 GB file size limit:

Many other Unix-based file systems (including Linux) may not support files > 2 GB (or > 4 GB in case they treat the file size as an unsigned 32 bit value) either, but could be improved in the future.

...even if I'm a long-time Linux fan and hate Windows to pieces. =) The reason is simple: less importantly, this paragraph is a bit speculative, but more importantly, it's apologist. It immediately raised the question: Yes, the free *nixes may be improved in the future, but won't the other OSes be improved too? And since they likely will be, what's the point of bringing this up, anyway?

If the technical facts are that the thrice-cursed, unholy Windows alone can do this properly, well, that's the sad state of the world. "But it will be in the next version of Linux, honest" just sounds a bit weird, unless we can show that yes, it will be coming. So, whoever wants to put that back should stick to facts, like statements from developers that the support will be included in Linux version X, or whatever. --wwwwolf (barks/growls) 13:20, 14 November 2006 (UTC)

Good points. The reason for me to mention the shortcoming is to raise awareness for this shortcoming. ISO 9660 is already pretty old, yet many important OSs (like BSD unix, OS X and Linux) have not added >2GB support to their drivers. And why? Because they're not even aware of this limitation. My hint that they could be improved in the future was meant to go in the direction of those who have the power to do that. But you're right, this does not really belong into an encyclopedia. And yes, I might as well contact the responsibles directly - but that's not easy (only in the case of OS X I actually did this, as Apple has a central bug reporting site for this, while I wouldn't know where to start with other Unixes or Linux). So, in a way, I hope that by raising awareness in this article, readers go ask the unix and Linux programmers to look into this. The mentioning that Windows XP can already do it is just to prove that it's actually working and in use already.

Tempel 10:25, 15 November 2006 (UTC)

A little bit of research would tell you that the standard linux filesystems are part of the kernel. kernel.org has a page on how to report bugs at http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html . having said that given the low level of practical significance of this bug (DVDs can be burnt with udf and with noone else supporting such files either there is unlikely to be a practical problem with existing media) i strongly suspect it will only be fixed if you submit a patch and possiblly not even then. Plugwash 10:29, 15 November 2006 (UTC)

Agreed - UDF, where available, could be used instead of ISO for files > 2GB, and it would be less of a problem finding a driver that supports that well.

However, I'll give you a hint where I find the ISO support necessary: If a Mac user wants to create a hybrid DVD (i.e. with HFS and ISO on it for x-platform readability), then the ISO side must be able to cope with files > 2GB. At this point, it's usually a bit late to change the format from ISO to a HFS/UDF hybrid just to satisfy this special need.

Besides, thanks for the link for bug reporting. I'll see what I can help (I also consider fixing the OS X driver myself already and submitting it back to Apple) -- Tempel 11:00, 17 November 2006 (UTC)

sorry, i just read what was on the talk page not the article contributions themselves, but still are there any programs that can generate such images in widespread use? Plugwash 17:04, 16 November 2006 (UTC)

I only know of one - the next version of a popular 3rd party CD recording software for Mac OS, based on the need described above. I can't say more yet ;) -- Tempel 11:00, 17 November 2006 (UTC)

Is there some reason why generating a hfs+/udf cd is problematic? I thought UDF was the reccomended format for dvds anyway. Plugwash 11:41, 17 November 2006 (UTC)

Yes, the reason could simply be one of practicability in the software generating such images - if it contains a working ISO generator, it might be easier to just add a little change to support multi-extents instead of adding an entirely new UDF generator, you know ;) -- Tempel 13:51, 18 November 2006 (UTC)

Update on current state of FreeBSD and NetBSD: Readable are data files up to 4 GiB - 1. Larger files are misrepresented depending on mount options. A detailed assessment for NetBSD is part of this change proposal: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48959 Symptoms on FreeBSD are the same. The remedy would have to be different, though, because of the 32 bit size of ino_t. 87.167.135.227 (talk) 07:45, 22 July 2014 (UTC)

Unofficial formats

I removed this entry, as I believe it is incorrect (see below). There is nothing in ISO-9660:1988 that prescribes the physical medium on which an ISO-9660 file system can be stored. The standard does refers to CD-ROMs exclusively, but that must be interpreted in the context in which it was written, i.e. 1988 (or CD-R should be consider non-standard as well). Nor can I find anything relevant to 'official use'. Either some particular use conforms to ISO-9660 specs, or it doesn't. As far as I can find, ISO-9660 on DVD conforms to specifications -- or is there some detail I have missed?Athulin (talk) 10:53, 19 June 2011 (UTC) Clarified: Athulin (talk) 12:00, 26 December 2014 (UTC)

The removed text was as follows:

Unofficial formats

It is quite possible to author data DVD discs in ISO9660 format and indeed most burning programs support the format (some as the default option). Although not an official use of ISO9660, practically every DVD drive will read single layer DVD discs in the format. Double layer discs are a bit more problematic, because not all drives will recognise dual layer ISO9660 discs. After all: they are treated as just a very large CD and there are no dual layer CDs. DVDs authored in this manner will show up as being in 'CDFS' format.