This bug shows up when mounting a multi-session ISO 9660 medium which has its directory tree above 4 GiB. (Not possible with CD, but with DVD or BD.) Obtain und uncompress http://scdbackup.webframe.org/large.iso.bz2 (Caution: 4470 bytes inflate to 4+ GiB.) Then mount it # mdconfig -a -t vnode -f large.iso md1 # mount_cd9660 /dev/md1 /mnt # find /mnt /mnt # ls -ld /mnt -r-xr-xr-x 1 root wheel 0 Jan 1 1970 /mnt The reason is that the byte address of the ISO 9660 Directory Records is encoded in ino_t, which on FreeBSD is 32 bit. If a record is stored above 4 GiB - 1, then rollover happens and it cannot be found. 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. See also http://lists.freebsd.org/pipermail/freebsd-hackers/2014-May/045139.html For my diagnosis and solution which cannot be ported to FreeBSD http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48787
Over to maintainers.
A commit references this bug: Author: cem Date: Sun Jan 8 06:21:50 UTC 2017 New revision: 311665 URL: https://svnweb.freebsd.org/changeset/base/311665 Log: cd9660: Expand internal inum size to 64 bits Inums in cd9660 refer to byte offsets on the media. DVD and BD media can have entries above 4GB, especially with multi-session images. PR: 190655 Reported by: Thomas Schmitt <scdbackup at gmx.net> Changes: head/sys/fs/cd9660/cd9660_lookup.c head/sys/fs/cd9660/cd9660_node.c head/sys/fs/cd9660/cd9660_node.h head/sys/fs/cd9660/cd9660_rrip.c head/sys/fs/cd9660/cd9660_vfsops.c head/sys/fs/cd9660/cd9660_vnops.c head/sys/fs/cd9660/iso.h head/sys/fs/cd9660/iso_rrip.h
A commit references this bug: Author: cem Date: Sun Jan 8 06:22:35 UTC 2017 New revision: 311666 URL: https://svnweb.freebsd.org/changeset/base/311666 Log: Do not truncate inode calculation from ISO9660 block offset PR: 190655 Reported by: Thomas Schmitt <scdbackup at gmx.net> Obtained from: NetBSD sys/fs/cd9660/cd9660_node.c,r1.31 Changes: head/sys/fs/cd9660/cd9660_node.c
Fixed in r311665, r311666. $ sudo mdconfig -a -t vnode -f large.iso md0 $ sudo mount_cd9660 /dev/md0 ./mnt $ find ./mnt ./mnt ./mnt/my ./mnt/my/large_file ./mnt/my/large_file ./mnt/small_file Thanks! Note, the multiple dirents for a single file with multiple segments issue remains (and is orthogonal). Was that fixed in NetBSD in a different PR?
Hi, Conrad Meyer wrote: > Note, the multiple dirents for a single file with multiple segments > issue remains (and is orthogonal). Was that fixed in NetBSD in a > different PR? I made a proposal as http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48959 Afaik it was not adopted yet. I remember to have later pondered about giving up the newly introduced file section counter in the inode number. It was originally planned when i slightly misunderstood the representation of large files in ECMA-119 / ISO 9660. The "Multi-Extent flag" gives more help than i thought. When i realized the misunderstanding, the new counter was already implemented and tested. (See in PR: "Information content of ino_t numbers", CD9660_INO_FSECT_BMASK.) In any case we would have to thoroughly review the patch. Currently i have some difficulties to remember my motivations and insights from 2.5 years ago. Maybe http://scdbackup.webframe.org/cd9660_level3_notes.txt can help to refresh my memory. If you consider to really implement large file support for cd9660, then i will of course be ready to help as good as i can. Just give me a note by mail. Have a nice day :) Thomas