Date: Mon, 13 Feb 2006 13:32:51 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@deepcore.dk> To: Chiharu Shibata <chi@bd.mbn.or.jp> Cc: freebsd-hackers@FreeBSD.ORG, re@FreeBSD.ORG, nork@FreeBSD.ORG, core@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: kern/60163 Message-ID: <43F07C73.6040502@deepcore.dk> In-Reply-To: <20060213121101.47A5AA98F@m-kg282p.ocn.ne.jp> References: <20060213121101.47A5AA98F@m-kg282p.ocn.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Chiharu Shibata wrote: > At Sun, 12 Feb 2006 17:02:37 JST, you wrote... > >>> To mount this DISC, your opinion is... >>> (1) at first, try "cdcontrol -f /dev/acd0c info" to make sure where >>> track is data area. >>> (2) type "mount_cd9660 -o rdonly /dev/acd0t13 /cdrom". >>> Is this right? >> Yeah that used to work at least, if not it needs fixing of course.. > > Hmm, succeeded under your environment... > >> Any chance you could put up a mirror of that disk image so I could burn >> me one exactly like it to test with please ? the one I had here of the >> sort seems to have gone amiss, making testing a pain.. > > My sample DISC is a commercial product. The copy is forbidden, of course. > However, about this problem, We may consider that it is not peculiar to > this product. > When I wrote that patch at first, some testers used another DISC, and > some result as me with/without patch. Well, without proper samples it'll be hard to work on this, if this is as common as suggested finding free samples that I can use for testing should not be a problem ? > > A various situation, my environment does not change/update-to-current. > So I will collect testers again and have it investigated whether it can > mount via /dev/acdNtY or not. > If it can, I will withdraw about "1st Problem". > > But "2nd/3rd Problem" remains as before, I want to ask your opinion > about these. > Moreover, the point that beforehand investigation of which track is > data area, this is very unreasonable restriction, I think. Hmm, could it be that the data track is always the last track ? You cannot compare SCSI/ATAPI behavior here, since the SCSI layer cannot handle ! %512 byte sectors it doesn't have to handle audio tracks. Native ATA/ATAPI on the other hand supports *any* sector size and needs to set the right sector size for each track. Now if you need a specific track you need to access that one via the acdNtY interface to gt the sector size right, if that fails I'll fix it :) Oh, and yes I'm talking 6.x and -current here, anything before that I don't support due to lack of spare time.... -Søren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43F07C73.6040502>