Date: Sun, 18 May 2014 20:15:45 +0200 From: "Thomas Schmitt" <scdbackup@gmx.net> To: freebsd-hackers@freebsd.org Subject: About a bug in cd9660 Message-ID: <20420668849133366718@scdbackup.webframe.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20420668849133366718>