[openbeosstorage] Re: ISO9660/cdrom progress

  • From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Tue, 25 Feb 2003 00:20:23 -0800

> > Looking at the root directory record, the location of the 
> > directory's
> > extent (an LBN) is always specified with an absolute block number.
> > One
> > could debate that the sequence # of 1, which is also always
> > specified,
> > refers to the volume space of the first session, which begins at 
> > zero
> > (even for the first data session immediately following an audio
> > session
> > on an "Enhanced Audio CD", interestingly). And while that's true,
> > addresses outside the first volume's volume space are still 
> > specified
> > this way. Further, every volume on the CD is always given the
> > sequence
> > # of 1.
> 
> Ouch!

The "production quality", pressed-not-burned CD that came with my 
lovely new Pocket PC actually references a volume sequence # of 0 in 
its addresses... 

> > I think there are two ways to look at the problem of handling
> > mutli-volume CDs, and I believe this is where we are failing to 
> > agree
> > (because I think we both mostly understand what's going on wrt the
> > standard).
> > 
> > I believe you are looking at the problem as "Here is the standard,
> > how
> > can we support a reasonably generic method of conveying volume set
> > information".
> 
> Exactly. Mainly because until now, I naively thought the CD burner
> applications follow the standard. :-)

What a silly idea. ;-)

> > I, OTOH, have been approaching it as "There is no standard followed
> > by
> > current burners (or Nero, at least; I guess others should be checked
> > too :-)
> 
> Oh, yes, please do that. :-) I can't, for I don't use Windows for
> religious reasons. ;-)

Ah, I see how it is. :-) Well, might you be able to check any of the 
burners available in Linux then? I don't have the patience to figure 
out how to get something as terribly complex as CD burning software to 
work. :-P :-)

Also, I recently inherited an iMac, so if I ever manage to get OS X 
installed (ironically, Linux installed with only the expected handful 
of hang-ups) and it turns out the thing has a CD-RW drive (I'm not sure 
if it does, and Linux isn't convinced yet that the drive even exists, 
despite being installed off of it...), I'll check out some Mac burners 
too.

[multi-volume-standard deviation woes]
> IMO users should be punished for using Windows applications, that 
> don't follow standards. ;-) I couldn't resist. :-P

Fair enough. :-) Other than not wanting to alienate potential converts, 
I would tend to agree (that, and I haven't bothered to figure out how 
to burn in BeOS yet, so I actually fall into that very category still 
:-0).

> Empty volume set ID, you say. Well, AFAIR the standard doesn't 
> disallow
> the empty string as a volume set identifier. So actually the volumes 
> on
> such an ill-formatted CD would naturally belong to the same volume 
> set.
> The sequence numbers would be wrong, but that can be dealt with
> gracefully.

<smacking forehead>
Wow. I feel much better about all this now. For some dumb reason, I was 
thinking all volumes with empty set ids should be placed into singleton 
sets, which would get messy for CDs with lots of volumes. Lumping them 
all together solves that nicely. :-)

> What concerns me more, is the CD-absolute addressing. Our ISO9660 FS
> would need to recognize the CD as an ill-formatted one and use 
> absolute
> addresses in this case, while for standard conformant ones the correct
> addressing would be used. I think, that should be feasible at least.

Well, as best I can tell, the one I'm using currently has no problem 
with any of the CDs I've thrown at it (though I haven't tested 
exhaustively), and I thought we got that one for free, as it comes in 
the R5 sample code.

> > Yes, though I see no evidence of any sort of restriction on where
> > files
> > can be referred from. It looks to me like any volume can refer to
> > anywhere on the disc it pleases (not according to the standard, but
> > according to actual CDs and their root directory records).
> 
> Sadly. Maybe one should notify the application creators of these
> standard deviations.

Yeah, I might do that. Maybe they'll counter with something along the 
lines of "you're using an old standard, go look at XYZ". :-) I'm not 
getting my hopes up, though.

[rumblings of disk_scanner interface and kernel migration changes]
> > I, too, am thinking about this, but this reply has taken me long
> > enough
> > to get sent off already, so it can wait till next time.
> 
> :-)
> No hurry. I haven't thought much about the matter yet. I first want to
> get the userland GUI add-ons done, with partitioning support, before
> actively reconsidering the registrar->kernel migration and the 
> required
> /useful changes.

How is the GUI add-on stuff going, btw? I still haven't gotten around 
to nosing around in what's been checked in. :-( 

As to the thinking...well, it's not quite done yet. :-)

-Tyler

Other related posts: