FreeLists / openbeosstorage / [openbeosstorage] Re: ISO9660/cdrom progress

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> [...]
> > + 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.

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.

> That files from other volumes can be `reused' is true, nevertheless. A
> directory record (cf. 9.1) has a `Volume Sequence Number' field
> identifying the volume on which the extend (== file contents) resides.
> 
> > + Volume Set IDs are used as a convenience for users only, and have
> > no
> > intrinsic meaning.
> 
> If you mean the ID itself, I think, you're right. Their usage does 
> have
> a meaning though, as it specifies, which volumes belong to the volume
> set.

Yes, that is what I meant. 

> > + Virtually no one ever records more than one volume at once, so 
> > each
> > volume gets put in its own "track" in its own "session" on the CD.
> > The
> > only exceptions I've seen are the R5 CD, with three volumes in a
> > single
> > "session", each in its own "track", and Video CDs, whic are a data
> > "session" containing a single iso volume in one data "track" (with,
> > I'm
> > assuming, some sort of supplementart descriptor flagging the session
> > as
> > a Video CD) followed by an individual data "track" for eack video
> > file
> > containing the raw MPEG data (and incidentally, the iso has 
> > directory
> > entries for the video files that refer to the data stored in the
> > video
> > tracks).
> > 
> > What I think this means for us is that (barring further discoveries)
> > we
> > can't completely know which volumes form a set without parsing the
> > whole filesystem to look for references to othjer sessions, and even
> > that fails in the event that all the files in the volume are 
> > updated.
> 
> 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_scanner 
> 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". 

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 :-) 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_scanner, and I like the SupersededBy() interface proposed below. 
Do we want to address my secondary concern anywhere, and if so where? I 
think it's worth considering.

> > > A far as I understand the matter, the on-disk structures don't 
> > > span
> > > a
> > > tree. I see, that there is a list of volume groups per volume set
> > > (or
> > > a
> > > list of volume subset, if you want), and that presenting the 
> > > latest
> > > group of each volume set to the user would be the default behavior
> > > I
> > > can imagine (perhaps with an option to switch to older groups). 
> > > For
> > > the
> > > volumes are at FS level, I think the extended_partition_info and
> > > BPartition structure (not session_info/BSession) would need to be
> > > extended.
> > 
> > As far as I can tell, they can span a tree, but in practice they
> > seldom
> > do (it does appears that the standard dictates this is not possible,
> > but I've made discs in Nero that do this).
> 
> 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). 

> > It seems to me, that the overwhelmingly common case for session
> > inheritance is the case in which a single volume is repeatedly
> > updated
> > using the same volume name.  Thus, somewhat similarily to what you
> > suggest above, perhaps Tracker should present by default only the
> > lastest volume (by date) out of any set of volumes on a given CD 
> > with
> > identical volume names, and then present some way to switch to any 
> > of
> > the earlier volumes, if so desired.  And since this is a file system
> > dependent feature, perhaps we should add a flag to
> > extended_partition_info to indicate when this sort of multivolume
> > behavior should be used (I guess we'd need to add a date as well).
> > Thoughts?
> 
> 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_partition_info 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_scanner 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.

-Tyler