Re: ISO9660/cdrom progress

Tyler Dauwalder <tyler-cyCl/[email protected]> 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