[openbeosstorage] Re: ISO9660/cdrom progress
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2003 00:22:56 -0800
> > that leads up to each leaf session, but once we know that, I doubt
> > it's=3D20
> > much more (if any) work to know the whole tree.=3D20
> >
> > For Tracker then, we could maybe have something along the lines of
> > a=3D
> > 20
> > "session chooser" item in pop up menus for volumes existing on=3D20
> > multi-session media that opens up a window showing the session=3D20
> > inheritance tree, allowing you to mount and unmount sessions at
> > will.
> > I=3D20
> > think that sort of interface would make CD backups a lot more
> > useful=3D
> > 20
> > (providing an easily accessible, almost CVS-like backup history).
>
> Yes, it probably makes the session chooser a lot more useful this
> way... but how would you provide that feature=3F Have a parent session
> field somewhere, and flag the sessions which doesn't have any children
> (since they are the main sessions)=3F
Yes, something like that. But it's not looking good wrt figuring out
the complete inheritance hierarchy...
On 2003-02-17 at 13:14:22 [-0800], Ingo Weinhold wrote:
> 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. ;-)
Good, now I know I sent you the right standard. ;-)
> 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.
Wow, I couldn't agree more. :-)
> 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.
Yes.
> 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.
Yes. For example, the Joliet volume name is in a supplementary
descriptor.
> But I have the feeling, they are not of real importance, anyway.
No, not really.
> 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).
This is the theory, at least. In practice, it doesn't appear to be used
in a useful way. With Nero at least, the volume set id may be set
arbitrarily by the user, and the sequence # appears to always be 1...
> * 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 withu
> 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.
I basically share your appraisal of the matter (though I overlooked the
volume group bit; damn you're thorough :-P :-). I personally wonder if
the majority of this mess is just never used. My impression of how
things are really working is this:
+ 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).
+ Volume Set IDs are used as a convenience for users only, and have no
intrinsic meaning.
+ 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.
>
> 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.
Yes. I think they do, though. I think that standard is only partially
used or incorrect or obsolete.
> About session/
> tracks/... I don't know, since those are not covered by the ISO9660
> standard (Tyler?).
A cd is composed of sessions, and sessions are composed of tracks.
Usually data sessions contain data tracks, and audio sessions contain
audio tracks, but it's not technmically required. The way I'm handling
thing currently, each track in a data session ends up being a
disk_scanner session, while the entirety of an audio session (with all
its tracks) is treated as a disk_scanner session.
> But I can't see, how that should affect the FS
> layer
> anyway.
No, it has little or no bearing on it.
> 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.
I believe Nero just shows the physical layout of the disc. At least, I
haven't been able to get it to show an inheritance hierarchy.
> > > 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.
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).
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?
-Tyler
Other related posts:
