From owner-freebsd-current Sun Sep 27 20:34:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20009 for freebsd-current-outgoing; Sun, 27 Sep 1998 20:34:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA19915; Sun, 27 Sep 1998 20:34:01 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id CAA02773; Mon, 28 Sep 1998 02:32:45 +0100 From: Luigi Rizzo Message-Id: <199809280132.CAA02773@labinfo.iet.unipi.it> Subject: Re: cd9660 mounts... To: tlambert@primenet.com (Terry Lambert) Date: Mon, 28 Sep 1998 02:32:44 +0100 (MET) Cc: wollman@khavrinen.lcs.mit.edu, dan@math.berkeley.edu, sos@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199809272133.OAA00234@usr05.primenet.com> from "Terry Lambert" at Sep 27, 98 09:32:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > mount -t cd9660 -o track=-1 /dev/cd0c /cdrom > > > > ..which would cause it to find the last track with an ISO-9660 > > filesystem on it, and mount that. (The current behavior is totally > > broken for PhotoCD, since there are normally garbage tracks after the > > one which contains the real data, so I always have to use ``cdcontrol > > info'' and do the scanning manually.) > > FWIW, this is supposed to be the default behaviour for a multisession > CD, according to the Joliet spec. (go to the last session with a > CD9660 FS, and mount it). our code does something like that now, but my feeling is that is is broken. Essentially the problem is: when a track is not at offset 0 who is in charge of adding the offset for the track to all reads ? * If you do it in the driver as i did, it is only one place to modify. * if you do it in the cd9660 fs code, i think you have to trap all code paths which end up in doing a bread(). I tried this but probably failed to find all of them. * there is a possibility (I don't have the cd9660 specs) that in a multisession CD, the data track is created knowing exactly where it is going to go on a disk (and what is on the previous tracks) so the track image already contains the correct block addresses and no offset needs to be added. The FreeBSD cd9660/mount_cd9660 _might_ work in the latter case, but i don't have a multisession CD to try and I want to remark that mkisofs has no flags/options to create this kind of tracks. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message