[openbeosstorage] Re: ISO9660/cdrom progress
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 21 Feb 2003 22:39:02 +0100 CET
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
>
> > [...]
> > > + Any volume on a CD can potentially reference data in any other
> > > volume
> > > on the same CD, regardless of session boundaries, due to the use
> > > of
> > > absolute addresses (that last bit I haven't verified, but I do
> > > know
> > > that files that aren't changed inbetween inherited sessions
> > > aren't
> > > rewritten, based on session sizes).
> >
> > I'm not so sure about the absolute addresses. They usually use the
> > term
> > `logical block number' (I haven't checked all structures, but I
> > believe
> > they do) and, as introduced in 6.2.2, they identify the blocks in
> > the
> > volumes space, i.e. on the volume (numbering starting with 0).
>
> 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!
> I guess my point is that I don't feel the volume sequence numbers
> ever
> have any real relevance anywhere, in practice at least (despite what
> the standard says). You certainly can't use them to bounds check LBN
> addresses against a volume space, nor to identify a volume's position
> in a sequence.
I see. :-(
> > I disagree. Unless you indeed have an sample CD which violates the
> > standard, but works on Windows (and other OSs). Which volumes
> > belong
> > to
> > a volume set is clearly defined by the standard -- those having the
> > same volumes set ID -- and recognizing that requires nothing more
> > than
> > reading the primary volume descriptors. In practice, this may turn
> > out
> > to be a bit difficult to do with our current disk=5Fscanner
> > architecture.
> >
> > Regarding which volume reuses data from which former ones, you're
> > right. Potentially this could be all in the volume set, but
> > actually I
> > don't find that information of much interest, anyway. Interesting
> > are
> > the volume groups IMHO.
>
> 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. :-)
> 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. ;-)
> that conveys to us automatically, without the user consciously
> planning ahead and using appropriate volume set ids (which have no
> meaning on Windows, and likely elsewhere), which volumes are in a
> set.
> Due to the nature of Windows (wherein only the last volume on the
> disc
> is ever displayed), most multi-volume CDs in existence will likely be
> a
> single set of volumes, all with identical volume names, all with an
> empty volume set id. Thus, how can we display to the user the
> intended
> set of volumes, since no provision has been made and/or followed to
> automatically convey that information to us."
>
> My concern is that muli-volume CDs with no volume set information
> (which I believe will describe most multi-volume CDs already made
> under
> Windows) will have all of their volumes displayed to the user by
> default, thus presenting a potentially large array of identically
> named
> volumes and making the user long for the ignorant bliss of Windows.
>
> So, to address what I believe your main concern has been: yes, I
> agree
> that standard volume sets can and should be handled by the
> disk=5Fscanner, and I like the SupersededBy() interface proposed below.
> Do we want to address my secondary concern anywhere, and if so where=3F
> I
> think it's worth considering.
IMO users should be punished for using Windows applications, that don't
follow standards. ;-)
I couldn't resist. :-P
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.
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.
[...]
> > Let me see, if we actually agree, but just think of different
> > levels:
> >
> > * The organization level is defined explicitely by the standard:
> > There
> > are volume sets, which consist of volume sequences, which are
> > factorized by creation time into sequences of volume groups. Each
> > volume group can reuse any data of the former ones. No trees here.
>
> Yes, though I see no evidence of volume sequences being implemented
> as
> the standard dicatates.
>
> > * A second structural level is implied by the reusage of files from
> > other volumes in a volume. Since files from any volume from the
> > volume
> > set can be referred,
>
> 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.
> > For the DiskDevice API I could imagine to add two methods,
> > BPartition
> > *
> > Supersedes() and BPartition *SupersededBy() to BPartition. Relating
> > this to the terminology of the standard, this reflects the list of
> > volume groups. The Tracker would simply present the tail of the
> > list
> > as
> > default and the others as options (e.g. an entry in the mount menu
> > could have a submenu listing all options).
>
> This I like.
>
> > Regarding the extended=5Fpartition=5Finfo structure I think it could be
> > extended by two fields specifying the session and partition index
> > of
> > the superseded partition (-1 for `normal' partitions). I would try
> > to
> > avoid adding too many specifics of this particular standard. A time
> > field wouldn't harm, but we would also need another field with the
> > volume set identifier, which doesn't fit very well, I feel.
> >
> > The interface for the disk=5Fscanner modules would need to be
> > adjusted
> > in
> > any case. I will think about this.
>
> 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.
CU, Ingo
Other related posts:
