About a bug in cd9660

[Thomas Schmitt]

Hi,

two years ago, i reported a cd9660 problem with multi-session ISO 9660
where the last session begins above 4 GiB.
  http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038570.html
  
This bug is fixed now in NetBSD
  http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48787

The problem was a 32 bit rollover of the inode number. This number
is simply the byte address of the ISO 9660 directory record, which
caused the existence of the inode.
The inode number is used to access this byte address for resolution
of symbolic links, and for accessing directories.
NetBSD has 64 bit ino_t. So adding a cast operator to the generation
of the inode number fixed the problem.

By webinterface i believe to see it in current FreeBSD source, too.

The rollover in function isodirino():
  http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_node.c?v=FREEBSD10#L319

The reverse computation of the directory block address
  http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_vfsops.c?v=FREEBSD10#L773

The reverse computation of the byte address of the directory
record of a symbolic link target
  http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_vnops.c?v=FREEBSD10#L692

And the reason why the NetBSD remedy will not help FreeBSD
  http://fxr.watson.org/fxr/source/sys/_types.h?v=FREEBSD10;im=3#L46
At least on my olde FreeBSD-8.4, sizeof(ino_t) is really 4.

For the purpose of directory addressing, the problem could be postponed
up to a limit of 128 GiB by dividing the byte address by 32 (or 34 if
one wants to squeeze out the record size guarantee of ISO 9660).
See (meanwhile retracted) proposal
  http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48797

But the task of symbolic link resolution will need to be implemented
without relying on the inode number.


I am willing to help fixing this problem in FreeBSD, but am currently
still busy with learning how to interface with NetBSD kernel and
(very friendly) community. There is another problem to be solved.
Files larger than 4 GiB show identical symptoms as on FreeBSD:
  http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038552.html

So additionally to my knowledge about ISO 9660 and my half-knowledge
about cd9660 filesystem code, there would be the need for somebody
who knows how to properly implement what will be determined to be
necessary.

Actually i believe the existence of 32 bit ino_t leaves FreeBSD
no choice but to get rid of the ino_t-to-address hacks in cd9660.


Have a nice day :)

Thomas