[openbeosstorage] Re: ISO9660/cdrom progress
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 17 Feb 2003 22:14:22 CET (+0100)
Hi,
Yesterday evening (or night) I read through this ECMA-119 standard
(claiming to be technically with the ISO9660 standard) and am not sure,
if I know much more now. ;-)
What I'm sure about is, that this standard is quite a bad exercise.
They define the structures, but fail utterly to present the intended
meanings.
However, here is my image of the whole thing:
* A volume is a continuous space on disk (it isn't said that
explicitly, though). It contains exactly one primary volume descriptor,
which identifies the volume, specifies its size, dir structure and a
lot of other things. What the optional suplementary volume descriptors
are good for, I'm not really sure. It sounds a bit like they contain
the same info as the primary descriptor, but use another character set.
But I have the feeling, they are not of real importance, anyway.
I believe, a volume resides on a (probably virtual) partition, not
sharing it with other volumes.
* A volume set is set of volumes with the same volume set identifier (a
string, BTW). Each volume of the set has an individual sequence number
(an integer).
* A volume group is a subset of of a volume set. The volumes it
contains, have consecutive sequence numbers and have been recorded at
the same time, i.e. have the same time stamp (not sure whether this
means creation or effective time). Each volume has a so called volume
set size, which is the number of the last volume within its volume
group. From the standard: `Each volume of a volume set shall contain a
description of all the directories and files that are recorded on those
volumes the sequence numbers of which are less than, or equal to, the
assigned volume set size of the volume.'
I would interpret that like this: At a time one can record a volume
group -- I suspect, they all go into one session (maybe together with
other volume groups). The volume group containing the volume with
sequence number 1 makes up a volume set. The next volume group I record
with the same volume set identifier establishes a new volume set
containing also the volumes of the previous group, but with another
directory/file structure.
What I don't understand is, what sense it should make, if one can have
several volumes per group, although all volumes of a group must define
the same directory hierarchy (path table). Unless I'm missing some
essential feature, I think, in practice groups will contain only one
volume.
Moreover I don't understand the use of volume partitions. Besides the
primary and none or more supplementary volume descriptors, there can
also be an arbitrary number of volume partition descriptors on a
volume, which define nothing more than location, size, identifier and
character sets of the volume partition.
Axel wrote:
> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > > What
> > > about the chronological order of the volumes on disk -- is it
> > > implied
> > > (by the order of appearance) or explicit (time stamp)=3F
> > Not sure. Possibly both.
>
> No, I don't think it's that - I dunno if anyone knows Nero, but there
> you can actually choose the session to use in a nice tree.
> So you could do things like:
> 1. session
> 2. session based on 1. session
> 3. session based on 2. session
> 4. session based on 2. session
>
> Then you should (IMO) give the users the choice between session 3 &
> 4,
> since they are the latest sessions in their set.
If I interpret, what I read, correctly, a volume can't explicitly refer
to another. They can be in the same volume set at most. About session/
tracks/... I don't know, since those are not covered by the ISO9660
standard (Tyler?). But I can't see, how that should affect the FS layer
anyway.
I wonder, if, what Nero presents, is deduced knowledge. By analyzing
the directory hierarchy of a volume (group) it is certainly possible to
find out, on which volumes the referred-to files are located.
> > This is, afaik, not defined. Windows always presents the last
> > session
> > on the CD, regardless of whether it is part of a set (even if there
> > are
> > previous sessions that are *not* part of any set). R5 presents
> > everything. I would like to see us present the last session of each
> > set
> > on the CD by default (treating independent sessions as one-volume
> > sets), and offer the option of choosing or switching to earlier
> > sessions for multi-volume sets.
>
> Something like this, yes - I think it would be enough flag the main
> sessions on the disk, so that Tracker only shows those. Optionally,
> it
> should be able to show all sessions on the disk, though (not
> necessarily the correct tree, that would be overkill).
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.
CU, Ingo
Other related posts:
