ISO9660 records and directory management

Each file or directory in an ISO9660 volume is described by a record. This record contains various informations related to the file or directory :

• The length of the record
• The location of the file/directory (sector number)
• The size of the file/directory
• The length of an eventual extended attribute record
• Some flags describing the record
• Identifier (name) length and content of the record.

In an iso9660 volume, a directory is in fact a list of these records. A file and/or directory always occupy a integer number of sectors : the remaining bytes of the record are filled with zeros. The different record from the record list of a directory cannot struggle over two sectors, if there is not enough space in a sector for a particular record, it's stored in the following sector.

Each directory contains at least two records : 

1. the first one describes the current directory (location, length, etc.) : this is the record of the commonly known "." special file, although in a iso9660 volume the identifier of such a record is "\0" (a single zero byte).
2. the second one describes the ".." special file and specify the location and length of the parent directory, excepted for the root directory of the volume : this record also act like a current record.

Since these record describe almost all data we need for a particular node of the filesystem (location on the volume, name, length, ...) they are used in the node management in the ISO9660 implementation.

After a first proof of concept where I was able to dump various directory information and navigate in an iso9660 volume in the shell through ls, I did a big refactoring of the record management layer and wrote dedicated functions to this purpose (see iso9660_record.c). This refactoring allows a cleaner and more efficient code. I spent hours in debugging a little mistake in the iso9660_record_create function which allocate memory and fill the various elements of the structures according to the directory record passed in parameter ; RTEMS was simply halting the CPU because of heap allocation problems. After a long track down of this bug I identified the incriminated line : a malloc(sizeof(name_len) * sizeof(char)) . The first sizeof has nothing to do there, Eclipse auto-completion killed me.

When creating a node (in the evalpath handler for example), we have to define a set of handler for a particular file type. In a ISO9660 (at least, without extension) volume, we have only two types of node : files and directory.

I preferred to deal with directory management first because I can't see the volume structure, I can't guess where the files are.

The next bunch of work will concern the file management and a enhanced cache manager : actually the cache is allocated on a per-node basis (i.e: a 2048 byte cache for each opened directory node), this is fairly inefficient and not very handy for file access management.