Re: kern/43963: libsa cd9660.c pathname lookup problem

[Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>]

Hi,

>         cd9660_open() traverses the ISO9660 path table incorrectly,
>         and fails to open files in subdirectories.
>         I'm afraid the author misunderstood the order of the entries.
>         Note it can open any files in the root directory successfully.

No, that's not correct.  The author (yours truly) understood the order
of the entries in the path table quite well.  It is mkisofs which is
at fault here.

You can check it yourself by looking at "6.9.1 Order of Path Table Records"
in the ISO 9660 specification (to be found e.g. at
http://www.ecma-international.org/publications/standards/Ecma-119.htm)
There it says that the main criterion for the order is the level in the
directory hierarchy, i.e. the list starts with all the entries at level
1 (by definition only the root directory), then all the entries at level
2 (all the entries in the root directory), then all entries at level 3
and so on. The second criterion then specifies that the entries at some
level are to be sorted according to the directory number of their parent
directory.

So the code is totally correct in terminating the search loop when finding
a directory entry with a different parent directory identifier number.

Now I'm (more or less) indifferent to lifting the insistance on correctly
written 9660 filesystems (there is already another workaround in the kernel
9660 implementation for incorrectly sorted directory entries in the main
directory tree), however, in that case you should probably restart the
search at the top of the path table after identifying a path component,
in order to be even more tolerant to incorrectly formatted filesystems.

Fixing mkisofs would be my preferred solution here (as the code in question
is only used during boot, we don't have to support reading CDs from
different sources anyway.)

Ciao,
Wolfgang
--
Wolfgang%Solfrank.net@localhost                          Wolfgang Solfrank