티스토리 툴바

블로그 이미지
Claid
Guru말고 Nerd를 지향합니다.

calendar

    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Notice

티스토리 모바일 블로그
크리에이티브 커먼즈 라이선스
Creative Commons License

Wiki 출처 : http://ko.wikipedia.org/wiki/ISO_9660



ISO 9660

ISO 9660은 국제 표준화 기구(ISO)에서 제정한 CD-ROM 매체를 위한 파일 시스템 표준이다. 이 표준은 마이크로소프트 윈도맥 오에스 텐유닉스 계열 운영 체제를 비롯한 서로 다른 운영 체제에서 작동할 수 있도록 설계되었다. DVD에서도 ISO 9660 파일 시스템을 사용할 수 있으나 실제로는 ISO/IEC 13346 UDF가 큰 데이터에 더 적합하므로 더 많이 사용된다.

ISO 9660 형식으로 저장된 CD-ROM 이미지 파일은 보통 .iso 확장자를 사용한다.

바깥 고리




출처 : http://users.telenet.be/it3.consultants.bvba/handouts/ISO9960.html


The ISO 9660 File System

This article describes the ISO 9660 file system format used on compact disc read only memory (CD-ROM). CD-ROMs have become so popular (and cheap) that its market share grew exponential over the last years. Therefore, it is worthwhile to examine the file system used on CD-ROMs. What makes it different to other file systems such as the UNIX File System (UFS) used on e.g. SunOS systems?

Gratien D?haese 
Alcatel Bell 
Switching Systems Division 
May 1995 
 



Introduction

The audio compact disks are only one decade old, but surprisingly enough it pushed the vinyl records completely from the market. It was in the beginning of the 1980s that Philips and Sony introduced the Compact Disc Digital Audio (CD-DA) Standard, better known as the Red Book standard.

It was also Philips and Sony who introduced in 1984 the CD-ROM (Compact Disc Read Only Memory) standard, which is commonly known as the Yellow Book standard.

The computer industry immediately saw the benefits of CD-ROMs, namely:

· cheaper in production than tapes

· cheaper in shipping to customers

· less vulnerable to dust, fingerprints, magnetic fields than tapes

· large capacity, more than 600 Mbytes

· cannot be overwritten by accident, because it is a read-only medium

Therefore, it did not take long before the CD-ROM became quiet popular among developers and customers.

However, to make a CD-ROM was until last year problematic because for mastering a CD-ROM special equipment was needed. These so called CD-writers have become affordable now, so that making a CD-ROM master (which can also be read with normal CD drives) is no big deal anymore. Making duplicates (the silver CD-ROMs) from a master (the golden CD-ROM) costs about 60 BEF a piece, which is a fair price!

The only problem was that CD-ROMs were not interchangeable amongst different computer architectures. The ISO 9660 standard was created to define the external characteristics of data on a CD-ROM to make it architecture independent. The first standard did not quite go far enough, so an ad hoc committee of hardware and software suppliers met at the High Sierra Hotel in Nevada (USA) and drew up a proposal for the ?High Sierra? format for CD-ROM file structure. The previous ISO 9660 standard and the High Sierra file structure were combined into a complete ISO 9660 standard (1988).

There are almost 6 million CD readers sold until now, which proves that CD-ROMs are a very popular medium among the commercial and non-commercial end-users.

Colour books of standards

The Compact Disc Digital Audio (CD-DA) standard (or just CD) made by Philips and Sony in the early 1980s became the de facto standard for all audio discs, and means that any CD plays on any audio CD drive. This standard became known as the Red Book. The Red Book specifies that the audio data is on the CD in one or more tracks. Each track is normally one song. These tracks are further subdivided into sectors that are 1/75 of a second in length and contain 2352 bytes of audio data in digital form. A maximum of 99 audio tracks may be placed on a standard Red Book disc.

In addition to the 2352 bytes of audio data, the Red Book specifies the addition of 2 layers of error detection and error correction code (EDC/ECC). The compact disc utilises the Cross Interleave Reed-Solomon Code (CIRC) in its first two layers of error protection. If a disc gets scratched or dirty and a laser cannot read the data, the CD player uses the CIRC to recreate the music.

Each sector is also assigned 98 control bytes, which control the timing information that the CD player uses to display the length of each song.

The Yellow Book standard was introduced by Philips and Sony in 1984 which defined the Compact Disc Read Only Memory (CD-ROM) layout.

The Yellow Book further defined the Red Book by adding two new types of tracks.

The track type defined in the Red Book is:

· CD-Audio, for audio music.

The two new track types defined in the Yellow Book are:

· CD-ROM Mode 1, usually used for computer data.

· CD-ROM Mode 2, usually used for compressed audio data, and video/picture data. Also, usually further defined as XA (eXtended Architecture).

The CD-ROM Mode 1 and Mode 2 tracks use the Red Book specifications as a foundation. The difference between the Red Book and the Yellow Book is a redefinition of the 2352 byte Red Book data area.

Furthermore, the Yellow Book CD-ROM Mode 1 and Mode 2 use the same track layout as the Red Book specification, including the error correction and control bytes. The fundamental difference between the two Yellow Book CD-ROM modes is the way in which they use the main data segment.

The Yellow Book CD-ROM Mode 1 defines the ISO 9960 and non-ISO 9660 standards. The ISO 9660 compliant CD-ROMs are readable by any kind of (modern) operating systems, such as DOS, UNIX, MacOS, AmigaDOS and other OSes.

The CD-ROM Mode 1 divides the 2352 byte data area defined by the Red Book standards into the following:

· 12 bytes of synchronisation

· 4 bytes of header information

· 2048 bytes of user information

· 288 bytes of error correction and detection codes.

The first 16 bytes contain the synchronisation and header information that the computer uses to determine which sector it is reading. The following 2048 bytes contain the actual user data. Together, these two subdivisions comprise the full 2352 byte portion of the Red Book standard.

The last 288 bytes carry an additional layer of error correction and direction code. This additional layer, which is found only in Mode 1, provides the reliability that is needed for certain types of computer data.

CD-ROM Mode 2 redefines the use of the 2352 byte data area as follows:

· 12 bytes of synchronisation

· 4 bytes of header information

· 2336 bytes of user data.

The main advantage of Mode 2 is that it provides an additional 14 per cent of the user data space per sector (2336 versus 2048 bytes). The reason is that Mode 2 does not have the additional EDC and ECC error correction data of Mode 1.

Mode 2 discs are normally used in extended architecture (XA) format. Even without XA, there are still two layers of error correction as defined in the Red Book standard. CD-ROM Mode 2 discs can be read by a standard CD-ROM drive, but require special software to decode and strip the user data from each sector.

CD-ROM Mode 2 allows compressed audio data and video/picture data to be incorporated on the disc, thanks to the alignment of the byte layout. The drawback is that a CD-ROM drive reading this data cannot read computer data while it?s playing audio.

The next step in CD technology was to create a file format that lent itself to the incorporation of audio and video/picture data. To define this extension to the Yellow Book standard, Sony and Philips produced the Compact Disc Read Only Memory Extended Architecture (CD-ROM/XA). The XA disc has compressed audioand computer data interleaved on the same track, so it can read the computer data and play audio on the same time.

This was a dramatic improvement on existing Yellow Book technology, and marks the point from which application discs that made best use of CD-ROM technology started to develop. CD-ROM/XA Mode 2 is subdivided into Form 1 (for computer data) and Form 2 (for compressed audio data and video/picture data).

The Compact Disc Interactive (CD-I) Media standard was released in 1987 by Philips. This standard specifies the CD-I disc layout and an operating system called CD-RTOS. This specification is known as the Green Book standard. Like CD-ROM/XA, this standard allows for the interleaving of computer data and compressed audio on the same track. The CD-I track is not shown in the table of contents on the disc. This prevents audio players from playing the CD-I track. The sector layout of a CD-I disc is identical to CD-ROM/XA. A CD-I system consists of a stand-alone CD-I player connected to a TV set.

Remember, the main drawback of a CD-ROM is, at least for some people, that it is a read-only medium (the ROM part of it?s name)! Writable mediums were needed to fulfil new (created) needs. In Frankfurt (Germany) a group was formed (guess the name) - the Frankfurt Group - which includes Philips, Sony, Kodak and others to take CD-ROM into the writable market. This became the Orange Book standard defining a CD that lets users write audio and/or data to disc. Part 1 of the Orange Book describes a Compact Disc-Magneto Optical (CD-MO) where data can be written, erased and rewritten. Part 2 describes a Compact Disc Write Once (CD-WO) where data can be written but not erased. The CD-WO is better known under it?s name CD-R where R stands for recordable. CD writers are becoming quite popular these days (and affordable).

CD-ROM Hardware

CD-ROM drives in general function like any other write-protected disk drive, and the device driver level appear quite ordinary.

CD-ROMs do not have a fixed number of sectors in a fixed-arm position. Instead, an inward spiral of records is arranged to maintain minimal latency from record to record.

Furthermore, CD-ROMs are not random access, but rather sequential access, which is why they tend to be slow, because the head hunts to find the desired record. The sectors are indexed by track in the same way cylinder, head, and sector indices are used in a hard-disk drive. With SCSI, these sectors are hidden by logical address translation in the drive?s controller. Unlike with hard drives, a separate head is not used for timing information, so each time a CD-ROM is moved for random access it must search up and down the spiral in the vicinity the head let down to find the desired sector.

CD-ROM sector sizes are large, usually 2048 bytes per sector (larger sizes are possible). Therefore, the concept of logical sectors is introduced. Each logical sector, with a constant logical sector size (= the sector size), starts in a different sector from any other logical sector.

File Systems on CD-ROM

A CD-ROM may be mastered with any kind of information on it. Sun Microsystems, for example, uses the Berkeley UNIX UFS file systems on many CD-ROMs. This make them only usable on Sun equipment, which is no big deal for a bootable CD-ROM with an operating system on it, but for distributing general information it?s a big limitation.

However, because CD-ROMs are especially suited to volume publishing of information, a standard file system useful across many kinds of architecture is very desirable. Before there was a standard on this matter some were using the High Sierra format on CD-ROM, which arranged file information in a dense, sequential layout to minimise nonsequential access.

The High Sierra file system format uses a hierarchical (eight levels of directories deep) tree file system arrangement, similar to UNIX and MS-DOS. High Sierra has a minimal set of file attributes (directory or ordinary file and time of recording) and name attributes (name, extension, and version). The designers realised they could never get people to agree on a unified definition of file attributes, so the minimum common information was encoded, and a place for future optional extensions (system use area) was defined for each file.

High Sierra was soon adapted (with changes) as an international standard (ISO 9660-1988), and the ISO 9660 file system format is now used throughout the industry.

The ISO 9660 File System

An ISO 9660 CD-ROM is described in Figure 1.

  
  
Figure 1: ISO 9660 CD-ROM
A reserved field at the beginning of the disk is present for use in booting CD-ROM on a computer (system area). As a matter of fact its use was not specified by the ISO 9660 standard, but generally it is used for boot information.

Immediately afterwards, a series of volume descriptors details the contents and kind of information contained on the disk (something like the partition table of MS-DOS).

A volume descriptor describes the characteristics of the file system information present on a given CD-ROM, or volume. It is divided into two parts;

· the type of volume descriptor, and

· the characteristics of the descriptor.

The volume descriptor is constructed in this matter so that if a program reading the disk does not understand a particular descriptor, it can just skip over it until it finds one it recognises, thus allowing the use of many different types of information on one CD-ROM. Also, if an error were to render a descriptor unreadable, a subsequent redundant copy of a descriptor could then allow for fault recovery. 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.

The minimum requirement is that it has a primary descriptor describing the ISO 9660 file system and an ending descriptor (a variable length table that contains information on how many other descriptors are present).

Little/Big Endian

In order to accommodate the two common byte orders, Big Endian (680x0, Sparc) and Little Endian (80x86, Rx000), ISO 9660 has data types which allow either and consequently are twice as big.

For example, the 32-bit integer (0x11223344) is represented as the byte sequence (0x44, 0x33, 0x22, 0x11, 0x11, 0x22, 0x33, 0x44), which is essentially a binary palindrome.

This method is often referred to as 733 (section 7.3.3 from the ISO 9660 standard, both byte orders) and is represented in Figure 2. 
 

 
  
Figure 2: Both Byte Orders
  

Figure 2 illustrates, the Big Endian addressing model assigns or maps the lowest address to the highest-order (that is, the most significant or leftmost) data byte of a multibyte-scalar data item. The Little Endianaddressing model assigns or maps the lowest address to the lowest-order (least significant or right-most) data byte of a multibyte-scalar data item.

ISO 9660 Primary Volume Descriptor

The ISO 9660 primary volume descriptor describes the characteristics of the ISO standard file system information present on a given CD-ROM (refer to Figure 3).

The ISO 9660 primary volume descriptor acts much like the superblock of the UNIX file system, providing details on the ISO 9660 compliant portion of the disk. Contained within the primary volume descriptor is the root directory record describing the location of the contiguous root directory. (As in UNIX, directories appear as files for the operating system?s special use). Directory entries are successively stored within this region. Evaluation of the ISO 9660 filenames is begun at this location. The root directory is stored as an extent, or sequential series of sectors, that contains each of the directory entries appearing in the root. In addition, since ISO 9660 works by segmenting the CD-ROM into logical blocks, the size of these blocks is found in the primary volume descriptor as well.

A CD-ROM is only compliant to the ISO 9660 file system standard if there is a primary descriptor, and when there is an ending descriptor available (e.g., the volume descriptor constitute a variable length table which contains information on how many other descriptors are present).

It is possible to have many kind of file systems and information arrangements on a single CD-ROM. However, while many other kinds of descriptors can be used to optionally record non-ISO defined information contents, the primary volume descriptor is always present. It is even possible to have a Mixed Mode disc, containing audio tracks and data tracks on the same disc. The most common type of Mixed Mode discs is one where the first track on the disc is Mode 1 data (ISO 9660 or non-ISO 9660), and the remaining tracks on the disc are audio tracks. Another possibility is the so called Hybrid disc, which contains an ISO 9660 part and a non-ISO 9660 part (e.g. Apple HFS format). The popular magazine on CD-ROM called ?CD-ROM Today? is an example of an Hybrid disc.

Referring back to Figure 3, the first entry is the Volume Descriptor Type (type), where it can have the following values:

· Number 0: shall mean that the Volume Descriptor is a Boot Record

· Number 1: shall mean that the Volume Descriptor is a Primary Volume Descriptor

· Number 2: shall mean that the Volume Descriptor is a Supplementary Volume Descriptor

· Number 3: shall mean that the Volume Descriptor is a Volume Partition Descriptor

· Numbers 4-254 are reserved

· Number 255: shall mean that the Volume Descriptor is a Volume Descriptor Set Terminator.

  
  
Figure 3: File structure of an ISO 9660 primary volume descriptor
The second entry is called the Standard Identifier ( id) and is set to ?CD001? for a CD-ROM compliant to the ISO 9660 standard.

Another interesting field is the Volume Space Size ( volume_space_size) which contains the amount of data available on the CD-ROM. It is recorded according the 733 method (see Figure 4).

  
  
Figure 4: A dump of a file structure of an ISO 9660 primary volume descriptor
Figure 4 is a dump of a CD-ROM (made by the Belgian UNIX systems Users Group (B.U.U.G.) containing Linux 95) starting at logical sector 16 and we see the first 256 bytes (of the 2048 bytes). The rectangles made in Figure 4 are respectively the Standard Identifier, System Identifier, Volume Space Size (check if you can find the binary palindrome), Volume Set Size, Volume Sequence Number, Logical Block Size, Path Table Size, and the Directory Record for the Root Directory. Together with Figure 3 you can follow the parameters in Figure 4. Also, together with Figure 4 and Figure 5 you should be able to discover to way the Directory Record of the Root Directory is represented on a CD-ROM (explained in following paragraphs).

Directory-entry Format

A directory entry is a data structure that describes the characteristics of a file or directory, beginning with a length octet describing the size of the entire entry. Entries themselves are of variable length, up to 255 octets in size. Attributes for the file described by the directory entry are stored in the directory entry itself (unlike UNIX).

In Figure 5, the root directory entry is a variable length object, so that the name can be of variable length. (No other part in the directory entry is of variable length).

  
  
Figure 5: Data Structure of a CD-ROM file system directory entry
File Attributes

File attributes are very simple in ISO-9660. The most important file attribute is determining whether the file is a directory or an ordinary file.File attributes for the file described by the directory entry are stored in the directory entry and optionally, in the extended attribute record. The name length field specifies how long the name is and is limited to 31 characters.

Filenames

Filenames in ISO-9660 correspond to a DOS-like representation, with an uppercase, fixed-size base name, a delimiter (a period) to separate filenames from the extension, and a three-letter extension name (also uppercase). Directory names contain maximum 8 characters and do not have extensions.

With filenames the extension may be followed another delimiter (a semicolon) and a revision number of the file. For example, a typical filename would be FOO.BAR;1. There are additional restrictions on the type of allowed characters beyond that of alpha characters (0-9 and _).

The choice of filename is thus restricted to allow for the vast number of different systems that existed at the time the standard was determined. While the directory entries allow much larger names than this, the characteristics and size of the filename were developed to achieve level-one compliance with original High Sierra format.

Unfortunately, many systems with ISO 9660 capability are not compatible with the naming conventions. For example, on a UNIX system, a semicolon is used as a command delimiter in the shell interpreter.

To by-pass there problems the Rock Ridge Interchange Protocol (RRIP) was designed to allow users of POSIX and other UNIX like systems to remain much of the directory information that is in the native file system. This is important because there systems use directory entries for much more than just pointing to files. Directory entries can point to other entries (symbolic links) or to device drivers that are linked to peripheral devices such as hard disks, tape drives and CD-ROM drives (device files). The directory entry includes information that lets the system know what type of file it is dealing with, whether it is a regular file, directory, symbolic link, or device file. It also has information regarding who has permission to read, write and execute each file. Most of these systems are multi-users systems, and you would not want just anyone to be able to write to the device file that contains your operating system, because they could accidentally erase the entire operating system. On the other hand, permission may not set to tight, because it can make CD-ROM unusable for users when they have no read access to files.

File Pathname Traversal

There are two ways to locate a file on an ISO 9660 file system. One way is to successively interpret the directory names and look through each directory file structure to find the file (much the way MS-DOS and UNIX work to find a file). The other way is through the use of a precompiled table of paths, where all the entries are enumerated in the successive contents of a file with the corresponding entries. Some systems do not have a mechanism for wandering through directories, they obtain a match by consulting the table.

While a large linear table seems a bit arcane, it can be of great value, as you can quickly search without wandering across the disk (thus reducing seek time).

File Contents

The ISO 9660 standard says practically nothing about the contents of files themselves - they can contain any kind of data one wishes to store.

Although the ISO 9660 standard allows an optional extended attributes record (XAR) stored at the beginning of the file?s extent which can contain additional file attribute information. Extension attributes are simply a way to extend the attributes of files. Since attributes vary according to the user, most everyone has a different opinion on what a file attribute should specify.

The Rock Ridge extensions is an example of extended attributes to make POSIX alike file attributes (much like UNIX). Rock Ridge can also be used in a networked situation, since a single CD-ROM can be exported to a variety of different operating systems viewing the same files, while appearing to be in the local system?s native file structure format. In sum, Rock Ridge is heading in the same ?universal? direction of other file systems like the Network File System (NFS).

Conclusions

A lot of people are aware of the ISO 9660 standard and its significance in sharing CD-ROM data between different platforms. ISO compliant CD-ROMs are interchangeable and can be used on any type of system and architecture. However, the minimalism that helped make the ISO 9660 standard successful may sometimes be too minimal for specific applications (such as distributing POSIX based, bootable CD-ROMs). Because ISO 9660 does not adequately support the POSIX file system, the Rock Ridge Group was formed to develop ISO 9660:1988 extensions, which take advantage of the system-use area of the directory record (provided for in ISO 9660) to store complete POSIX file system information.

Extensions to ISO 9660 can make a CD-ROM appear like a given target operating system (such as a POSIX compliant file system). By encoding these extensions (using the sharing-use protocols), you can allow for separate sets of attributes for the same file system. This lets you organize extended information for different systems (such as VMS, DOS, and UNIX) in a nonconflicting way. Also, any system that only understands ISO 9660 without any extensions can still gain access to the files and obtain the exact same contents of data for a file. It is quite simple, if the extensions are not understood, they are not used at all. You get the best of both worlds: ISO compatibility and interoperability, and POSIX operating system transparency and functionality.

Technology is not standing still also, because Philips and Sony just proposed a new CD-ROM standard which could contains 2.3 Gbytes of data (almost 4 times more than current CD-ROM standard). Probably the current ISO 9660 standard has to be adpated too with new extension attributes for new applications (to be defined).

References





출처 : http://alumnus.caltech.edu/~pje/iso9660.html


ISO9660 Simplified for DOS/Windows
by Philip J. Erdelsky

1. Introduction

We weren't sure about it a few years ago, but by now it should be clear to everyone that CD-ROM's are here to stay. Most PC's are equipped with CD-ROM readers, and most major PC software packages are being distributed on CD-ROM's.

Under DOS (and Windows, which uses the DOS file system) files are written to both hard and floppy disks with a so-called FAT (File Allocation Table) file system.

Files on a CD-ROM, however, are written to a different standard, called ISO9660. ISO9660 is rather complex and poorly written, and obviously contains a number of diplomatic compromises among advocates of DOS, UNIX, MVS and perhaps other operating systems.

The simplified version presented here includes only features that would normally be found on a CD-ROM to be used in a DOS system and which are supported by the Microsoft MS-DOS CD-ROM Extensions (MSCDEX). It is based on ISO9660, on certain documents regarding MSCDEX (version 2.10), and on the contents of some actual CD-ROM's.

Where a field has a specific value on a CD-ROM to be used with DOS, that value is given in this document. However, in some cases a brief description of values for use with other operating systems is given in square brackets.

ISO9660 makes provisions for sets of CD-ROM's, and apparently even permits a file system to span more than one CD-ROM. However, this feature is not supported by MSCDEX.

2. Files

The directory structure on a CD-ROM is almost exactly like that on a DOS floppy or hard disk. (It is presumed that the reader of this document is reasonably familiar with the DOS file system.) For this reason, DOS and Windows applications can read files from a CD-ROM just as they would from a floppy or hard disk.

There are only a few differences, which do not affect most applications:

  1. The root directory contains the notorious "." and ".." entries, just like any other directory.
  2. There is no limit, other than disk capacity, to the size of the root directory.
  3. The depth of directory nesting is limited to eight levels, including the root. For example, if drive E: contains a CD-ROM, a file such as E:\D2\D3\D4\D5\D6\D7\D8\FOO.TXT is permitted but E:\D2\D3\D4\D5\D6\D7\D8\D9\FOO.TXT is not.
  4. If a CD-ROM is to be used by a DOS system, file names and extensions must be limited to eight and three characters, respectively, even though ISO9660 permits longer names and extensions.
  5. ISO9660 permits only capital letters, digits and underscores in a file or directory name or extension, but DOS also permits a number of other punctuation marks.
  6. ISO9660 permits a file to have an extension but not a name, but DOS does not.
  7. DOS permits a directory to have an extension, but ISO9660 does not.
  8. Directories on a CD-ROM are always sorted, as described below.

Of course, neither DOS, nor UNIX, nor any other operating system can WRITE files to a CD-ROM as it would to a floppy or hard disk, because a CD-ROM is not rewritable. Files must be written to the CD-ROM by a special program with special hardware.

3. Sectors

The information on a CD-ROM is divided into sectors, which are numbered consecutively, starting with zero. There are no gaps in the numbering.

Each sector contains 2048 8-bit bytes. (ISO9660 apparently permits other sector sizes, but the 2048-byte size seems to be universal.)

When a number of sectors are to be read from the CD-ROM, they should be read in order of increasing sector number, if possible, since that is the order in which they pass under the read head as the CD-ROM rotates. Most implementations arrange the information so sectors will be read in this order for typical file operations, although ISO9660 does not require this in all cases.

The order of bytes within a sector is considered to be the order in which they appear when read into memory; i.e., the "first" bytes are read into the lowest memory addresses. This is also the order used in this document; i.e., the "first" bytes in any list appear at the top of the list.

4. Character Sets

Names and extensions of files and directories, the volume name, and some other names are expressed in standard ASCII character codes (although ISO9660 does not use the name ASCII). According to ISO9660, only capital letters, digits, and underscores are permitted. However, DOS permits some other punctuation marks, which are sometimes found on CD-ROM's, in apparent defiance of ISO9660.

MSCDEX does offer support for the kanji (Japanese) character set. However, this document does not cover kanji.

5. Sorting Names or Extensions

Where ISO9660 requires file or directory names or extensions to be sorted, the usual ASCII collating sequence is used. That is, two different names or extensions are compared as follows:

  1. ASCII blanks (32) are added to the right end of the shorter name or extension, if necessary, to make it as long as the longer name or extension.
  2. The first (leftmost) position in which the names or extensions are not identical determines the order. The name or extension with the lower ASCII code in that position appears first in the sorted order.

6. Multiple-Byte Values

A 16-bit numeric value (usually called a word) may be represented on a CD-ROM in any of three ways:

Little Endian Word:
The value occupies two consecutive bytes, with the less significant byte first.
Big Endian Word:
The value occupies two consecutive bytes, with the more significant byte first.
Both Endian Word:
The value occupies FOUR consecutive bytes; the first and second bytes contain the value expressed as a little endian word, and the third and fourth bytes contain the same value expressed as a big endian word.

A 32-bit numeric value (usually called a double word) may be represented on a CD-ROM in any of three ways:

Little Endian Double Word:
The value occupies four consecutive bytes, with the least significant byte first and the other bytes in order of increasing significance.
Big Endian Double Word:
The value occupies four consecutive bytes, with the most significant first and the other bytes in order of decreasing significance.
Both Endian Double Word:
The value occupies EIGHT consecutive bytes; the first four bytes contain the value expressed as a little endian double word, and the last four bytes contain the same value expressed as a big endian double word.

7. The First Sixteen Sectors are Empty

The first sixteen sectors (sector numbers 0 to 15, inclusive) contain nothing but zeros. ISO9660 does not define the contents of these sectors, but for DOS they are apparently always written as zeros. They are apparently reserved for use by systems that can be booted from a CD-ROM.

8. The Volume Descriptors

Sector 16 and a few of the following sectors contain a series of volume descriptors. There are several kinds of volume descriptor, but only two are normally used with DOS. Each volume descriptor occupies exactly one sector.

The last volume descriptors in the series are one or more Volume Descriptor Set Terminators. The first seven bytes of a Volume Descriptor Set Terminator are 255, 67, 68, 48, 48, 49 and 1, respectively. The other 2041 bytes are zeros. (The middle bytes are the ASCII codes for the characters CD001.)

The only volume descriptor of real interest under DOS is the Primary Volume Descriptor. There must be at least one, and there is usually only one. However, some CD-ROM's have two or more identical Primary Volume Descriptors. The contents of a Primary Volume Descriptor are as follows:

     length
     in bytes  contents
     --------  ---------------------------------------------------------
        1      1
        6      67, 68, 48, 48, 49 and 1, respectively (same as Volume
                 Descriptor Set Terminator)
        1      0
       32      system identifier
       32      volume identifier
        8      zeros
        8      total number of sectors, as a both endian double word
       32      zeros
        4      1, as a both endian word [volume set size]
        4      1, as a both endian word [volume sequence number]
        4      2048 (the sector size), as a both endian word
        8      path table length in bytes, as a both endian double word
        4      number of first sector in first little endian path table,
                 as a little endian double word
        4      number of first sector in second little endian path table,
                 as a little endian double word, or zero if there is no
                 second little endian path table
        4      number of first sector in first big endian path table,
                 as a big endian double word
        4      number of first sector in second big endian path table,
                 as a big endian double word, or zero if there is no
                 second big endian path table
       34      root directory record, as described below
      128      volume set identifier
      128      publisher identifier
      128      data preparer identifier
      128      application identifier
       37      copyright file identifier
       37      abstract file identifier
       37      bibliographical file identifier
       17      date and time of volume creation
       17      date and time of most recent modification
       17      date and time when volume expires
       17      date and time when volume is effective
        1      1
        1      0
      512      reserved for application use (usually zeros)
      653      zeros

The first 11 characters of the volume identifier are returned as the volume identifier by standard DOS system calls and utilities.

Other identifiers are not used by DOS, and may be filled with ASCII blanks (32).

Each date and time field is of the following form:

     length
     in bytes  contents
     --------  ---------------------------------------------------------
        4      year, as four ASCII digits
        2      month, as two ASCII digits, where
                 01=January, 02=February, etc.
        2      day of month, as two ASCII digits, in the range
                 from 01 to 31
        2      hour, as two ASCII digits, in the range from 00 to 23
        2      minute, as two ASCII digits, in the range from 00 to 59
        2      second, as two ASCII digits, in the range from 00 to 59
        2      hundredths of a second, as two ASCII digits, in the range
                 from 00 to 99
        1      offset from Greenwich Mean Time, in 15-minute intervals,
                 as a twos complement signed number, positive for time
                 zones east of Greenwich, and negative for time zones
                 west of Greenwich

If the date and time are not specified, the first 16 bytes are all ASCII zeros (48), and the last byte is zero.

Other kinds of Volume Descriptors (which are normally ignored by DOS) have the following format:

     length
     in bytes  contents
     --------  ---------------------------------------------------------
        1      neither 1 nor 255
        6      67, 68, 48, 48, 49 and 1, respectively (same as Volume
                 Descriptor Set Terminator)
      2041     other things

9. Path Tables

The path tables normally come right after the volume descriptors. However, ISO9660 merely requires that each path table begin in the sector specified by the Primary Volume Descriptor.

The path tables are actually redundant, since all of the information contained in them is also stored elsewhere on the CD-ROM. However, their use can make directory searches much faster.

There are two kinds of path table -- a little endian path table, in which multiple-byte values are stored in little endian order, and a big endian path table, in which multiple-byte values are stored in big endian order. The two kinds of path tables are identical in every other way.

A path table contains one record for each directory on the CD-ROM (including the root directory). The format of a record is as follows:

     length
     in bytes  contents
     --------  ---------------------------------------------------------
        1      N, the name length (or 1 for the root directory)
        1      0 [number of sectors in extended attribute record]
        4      number of the first sector in the directory, as a
                 double word
        2      number of record for parent directory (or 1 for the root
                 directory), as a word; the first record is number 1,
                 the second record is number 2, etc.
        N      name (or 0 for the root directory)
      0 or 1   padding byte: if N is odd, this field contains a zero; if
                 N is even, this field is omitted

According to ISO9660, a directory name consists of at least one and not more than 31 capital letters, digits and underscores. For DOS the upper limit is eight characters.

A path table occupies as many consecutive sectors as may be required to hold all its records. The first record always begins in the first byte of the first sector. Except for the single byte described above, no padding is used between records; hence the last record in a sector is usually continued in the next following sector. The unused part of the last sector is filled with zeros.

The records in a path table are arranged in a precisely specified order. For this purpose, each directory has an associated number called its level. The level of the root directory is 1. The level of each other directory is one greater than the level of its parent. As noted above, ISO9660 does not permit levels greater than 8.

The relative positions of any two records are determined as follows:

  1. If the levels are different, the directory with the lower level appears first. In particular, this implies that the root directory is always represented by the first record in the table, because it is the only directory with level 1.
  2. If the levels are identical, but the directories have different parents, then the directories are in the same relative positions as their parents.
  3. Directories with the same level and the same parent are arranged in the order obtained by sorting on their names, as described in Section 5.

10. Directories

A directory consists of a series of directory records in one or more consecutive sectors. However, unlike path records, directory records may not straddle sector boundaries. There may be unused space at the end of each sector, which is filled with zeros.

Each directory record represents a file or directory. Its format is as follows:

     length
     in bytes  contents
     --------  ---------------------------------------------------------
        1      R, the number of bytes in the record (which must be even)
        1      0 [number of sectors in extended attribute record]
        8      number of the first sector of file data or directory
                 (zero for an empty file), as a both endian double word
        8      number of bytes of file data or length of directory,
                 excluding the extended attribute record,
                 as a both endian double word
        1      number of years since 1900
        1      month, where 1=January, 2=February, etc.
        1      day of month, in the range from 1 to 31
        1      hour, in the range from 0 to 23
        1      minute, in the range from 0 to 59
        1      second, in the range from 0 to 59
                 (for DOS this is always an even number)
        1      offset from Greenwich Mean Time, in 15-minute intervals,
                 as a twos complement signed number, positive for time
                 zones east of Greenwich, and negative for time zones
                 west of Greenwich (DOS ignores this field)
        1      flags, with bits as follows:
                 bit     value
                 ------  ------------------------------------------
                 0 (LS)  0 for a norma1 file, 1 for a hidden file
                 1       0 for a file, 1 for a directory
                 2       0 [1 for an associated file]
                 3       0 [1 for record format specified]
                 4       0 [1 for permissions specified]
                 5       0
                 6       0
                 7 (MS)  0 [1 if not the final record for the file]
        1      0 [file unit size for an interleaved file]
        1      0 [interleave gap size for an interleaved file]
        4      1, as a both endian word [volume sequence number]
        1      N, the identifier length
        N      identifier
        P      padding byte: if N is even, P = 1 and this field contains
                 a zero; if N is odd, P = 0 and this field is omitted
    R-33-N-P   unspecified field for system use; must contain an even
                 number of bytes

The length of a directory includes the unused space, if any, at the ends of sectors. Hence it is always an exact multiple of 2048 (the sector size). Since every directory, even a nominally empty one, contains at least two records, the length of a directory is never zero.

All fields in the first record (sometimes called the "." record) refer to the directory itself, except that the identifier length is 1, and the identifier is zero. The root directory record in the Primary Volume Descriptor also has this format.

All fields in the second record (sometimes called the ".." record) refer to the parent directory, except that the identifier length is 1, and the identifier is 1. The second record in the root directory refers to the root directory.

The identifier for a subdirectory is its name. The identifier for a file consists of the following fields, in the order given:

  1. The name, consisting of the ASCII codes for at least one and not more than eight capital letters, digits and underscores.
  2. If there is an extension, the ASCII code for a period (46). If there is no extension, this field is omitted.
  3. The extension, consisting of the ASCII codes for not more than three capital letters, digits and underscores. If there is no extension, this field is omitted.
  4. The ASCII code for a semicolon (59).
  5. The ASCII code for 1 (49). [On other systems, this is the version number, consisting of the ASCII codes for a sequence of digits representing a number between 1 and 32767, inclusive.]

Some implementations for DOS omit (4) and (5), and some use punctuation marks other than underscores in file names and extensions.

Directory records other than the first two are sorted as follows:

  1. Records are sorted by name, as described above.
  2. Every series of records with the same name is sorted by extension, as described above. For this purpose, a record without an extension is sorted as though its extension consisted of ASCII blanks (32).
  3. [On other systems, every series of records with the same name and extension is sorted in order of decreasing version number.]
  4. [On other systems, two records with the same name, extension and version number are permitted, if the first record is an associated file.]

[ISO9660 permits names containing more than eight characters and extensions containing more than three characters, as long as both of them together contain no more than 30 characters.]

It is apparently permissible under ISO9660 to use two or more consecutive records to represent consecutive pieces of the same file. Bit 7 of the flags byte is set in every record except the last one. However, this technique seems pointless and is apparently not used. It is not supported by MSCDEX.

Interleaving is another technique that is apparently seldom used. It is not supported by MSCDEX (version 2.10).

11. Arrangement of Directory and Data Sectors

ISO9660 does not specify the order of directory or file sectors. It merely requires that the first sector of each directory or file be in the location specified by its directory record, and that the sectors for directories and non-interleaved files be consecutive.

However, most implementations arrange the directories so each directory follows its parent, and the data sectors for the files in each directory lie immediately after the directory and immediately before the next following directory. This appears to be an efficient arrangement for most applications.

Some implementations go one step further and order the directories in the same manner as the corresponding path table records.

12. Extended Attribute Records

Extended attribute records contain file and directory information used by operating systems other than DOS, such as permissions and logical record lengths.

A CD-ROM written for DOS normally does not contain any extended attribute records.

When reading a CD-ROM containing extended attribute records, early versions of MSCDEX simply returned incorrect results. Later versions learned to skip over extended attribute records.

Philip J. Erdelsky
San Diego, California USA
pje@acm.org
http://www.alumni.caltech.edu/~pje/






프로젝트 때 공부하던 것을 정리해 둔다.




저작자 표시 비영리

'My Assignment > Embedded Programming' 카테고리의 다른 글

ISO9660  (0) 2012/05/07
HBE-ZigbeX의 Windows7 64bit 개발환경 잡기  (0) 2011/05/21
posted by Claid

Trackback | http://claid.tistory.com/trackback/22 관련글 쓰기

댓글을 달아 주세요

prev 1 2 3 4 5 ... 17 next