Date: Sat, 1 Feb 1997 17:55:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org Subject: Re: Mounting CD-ROM when data not on first track Message-ID: <199702020055.RAA07106@phaeton.artisoft.com> In-Reply-To: <Mutt.19970202011243.j@uriah.heep.sax.de> from "J Wunsch" at Feb 2, 97 01:12:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> As Terry Lambert wrote: > > > I believe this is a perfectly legal thing to do, actually. One wonders > > At least not in the sense of CD9660 (which i think has a crippled > idea in this respect). I'm not sure if I agree with the interpretation of CD9660 meaning "the first track of any session shall be a data track". I think I lean more towards "the first data track of any session is the first track of the session". > > why the cd device starts at the raw track one instead of the first data > > track in any case... > > Because it always starts at the beginning, and covers the entire data > area. You could look at it as if it were a huge sparse file in this > special situation: seek to the right location, and you'll be able to > read the data. But it's not a data area... or rather, it's not a 'data' area. > Btw., this is exactly what the normal ``multi-session'' idea of CD9660 > is: you've got the entire drive mapped, and the first track of the > most recent session contains the CD9660 directory structure, where the > block pointers are allowed to point back on the CD, or to point into > this track itself. (Strictly spoken, they are allowed to point into > the first track of each successive session only. See above.) That's > why they call this entire beast a session then, despite of the matter > that a single session might have multiple tracks. They always > siltently assume at most the first track of each session being in > CD-ROM data format. I looked at the Windows95 CDROM driver in Soft-ICE for a long time, mostly because it doesn't have the bogus "drive recogniton code" of VFAT implemented in the wrong logical layer, like VFAT. It has it's own bogus "media arrival" definition that doesn't use the device manager like it should, but that's neither here nor there. The Windows95 IFS module for the CDROM driver looks for the first data track of the last session on the device, if the last data track of the last session does not show it as a Joliet disc. If it is a Joliet disc (like I think it is), it would work, and if it's a CD9660 disc using the interpretation using my second sentence above, it would still work. Does anyone else have this CD? Do you have a MacOS or SunOS or older Windows box with ASPI or proprietary CDROM driver you can try it in? If the non-Joliet aware OS recognizes it, I'd think that the FreeBSD interpretation is probably wrong. I suspect they *must* have tested it on a Macintosh before they went to press on it... Quicktime is a native Mac format. > Our cd9660 filesystem code simply needs to examine the TOC (this can > be done from userland, since there's an ioctl for it), and if it > succeeds in this operation, it should default to the diretory > structure from the first track of the last session. Voila!, this > would allow us to read multi-session ISO-9660 CDs. > > The downside: _creating_ such a filesystem is way harder. mkisofs > currently always runs in standalone mode. For ISO-9660 CDs however, > it needs to examine the existing tree structure first (which can > already be multi-session), and needs to figure out which files are to > be replaced. It must then add them up to the new track, along with an > entire new directory tree. (Maybe partial new would suffice, if parts > of the tree remain untouched.) Things are even worse if audio tracks > lie between the data tracks, since mkisofs must retains the holes in > the block numbers, even if the data contents is unknown. The software we run on our mastering burners here knows about writing additional sessions. It does partial trees on the new session; I was recently burning through 12 or more sessions on a CDROM we were using to test install code modifications for autorun.inf for running an install chooser when the user inserted the disc. It seems that Microsoft (stupidly) can not force a program image to be entirely resident in memory, and will blue-screen if the image is from a disc that has been removed, and it wants to page from it. You can see this easily by installing the MSVC++ CDROM on a Win95 box where it's not already installed, letting the install screen pop up, removing the CDROM, and then moving the mouse around. The bitmap data for the buttons was not forced in, and it will attempt to page them from the file, and blue-screen. > > Finally, it seems to me that the CDROM device should impose "slices" > > on its own, and it makes sense to me that 'd' is the whole disk and > > that 'c' is the first data area. > > It makes no sense, i've already thought about this. There are up to > 99 tracks allowed, so we need up to 99 subdevices. Maybe 100, to > account for one covering the entire disk (subdevice 0 fits best for > this, since it's not a legal track number). Why would you need 99 sub-devices? Wouldn't you just *always* point the 'c' device at the first data area? Hmmmm... maybe we should wait until someone tries the CD in a non-Win95 box with a "known good" CD9660? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702020055.RAA07106>