Working directories

 I had a strange bug today which trashes the shell command prompt when changing to a sub-directory of the ISO volume. I fixed the faulty eval_path() handler which wasn't detecting well a filesystem change in the path, e.g: if the  iso9660 volume is mounted on /cdrom, an access to the path /cdrom/sub_dir/../../ results  in a fileystem change since / reside on an other file-system.

  This screenshot shows the basics of directory management in a iso9660 volume : the application is able to navigate through the folder structure. Note that the source ISO disk virtually inserted in the /dev/hdb drive has been created with mkisofs with all iso9660-compliancy options enabled : all file and directory names use a limited character set (i.e: caps only).
  The ECMA-119 standard defines three levels of implementation :

• Level 1 : 
• Each file consists of only one file section (a sector wide)
• The file should be formatted as "8.3" characters (8 characters for the name and 3 for the extension)
• A directory name should not contain more than eight characters
• The character set is limited to "d-characters" (digits, capital letters and underscore)
• Level 2 :
• Each file consists of only one file section
• Level 3 :
• No restrictions on file size

  With the directory handlers working I can start the file handlers. Currently only the "fstat" system call is implemented for files, and I will enhance its implementation with data found in "extended attribute records". These records are optional and gives some informations about the permissions of a given file.
  Those permissions will be really ready after the integration of the Rock Ridge extension which embed ACL in an ISO9660 among other things.

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.