[openbeosstorage] Re: ISO9660/cdrom progress
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sun, 16 Feb 2003 11:04:30 -0800
On 2003-02-16 at 06:21:24 [-0800], Ingo Weinhold wrote:
>
> [...]
> > > Er, I probably just don't know about multi-session CDs. A CD
> > > doesn't
> > > simply consist of sessions, but these sessions are grouped in
> > > volumes??
> > > If that is so, it should be an information the Disk Device API is
> > > able
> > > to provide.
> >
> > With iso9660 file systems, you can refer to file data from previous
> > sessions instead of duplicating the same data over again. So, say
> > you
> > have 20 files that you back up on a CD. Then a week later, you want
> > to
> > back them up again, but only one of them has changed. Instead of
> > writing all 20 files again, only the changed file will be written,
> > and
> > the remaining entries will just refer to the data in the previous
> > session.
>
> Mmh, that doesn't sound like something I like. If I understand you
> correctly, the file system needs to access other sessions than the one
> passed to it.
I believe so. I don't fully understand how it all works though, so I
could be wrong.
> > So, I think that it's not really a session add-on thing as much as a
> > file system add-on thing. With iso9660, I believe all the related
> > volumes have a common "volume set" identifier (I'd need to double
> > check
> > this, though). We'd probably need something similar to be able to
> > distinquish which volumes are part of a set and which volumes are
> > independent. We'd probably also need a way to designate the
> > chronological ordering of the volumes; either a datestamp or an
> > ordinal numbering, I suppose. I'm nearly done revamping the session
> > module, so I could look into the details of how iso9960 handles
> > things
> > after I finish. Thoughts?
>
Off the top of my head:
> Can you please elaborate a bit more on this -- best starting with the
> terminology. E.g. what is a volume? Is it a session, a track or a
> partition?
Just a recognized chunk of data formatted with iso9660, so I guess a
partition, from where we're coming from. I don't recall seeing this
nailed down very precisely in the standard. Volume is just the
terminology the iso9660 specs use.
> What is the volume set identifier -- a string, an int?
I believe a string, but I could be wrong. I'm not even sure that's
exactly what the volume set identifier is used for (again, the specs
are fuzzy), but I haven't had a chance to check yet.
> What
> about the chronological order of the volumes on disk -- is it implied
> (by the order of appearance) or explicit (time stamp)?
Not sure. Possibly both.
> When should a
> session, volume or volume set (or whatever) be invisible for the user,
> i.e. is the session,... burned latest always the only one visible, or,
> if not in general, under what circumstances? ...?
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.
> To save you some time, maybe it's better, if you sent a link. As you
> like... :-)
I will email you the specs, as I forget where I got them from
originally. :-) If you feel like playing with the volume descriptors on
an iso CD, the iso9660 add-on loops through all the descriptors on a
volume, and can easily be made to print out more information about/from
each it encounters.
> I really want to understand the problem completely first.
Understood. :-) I certainly don't fully understand it at the moment
either. :-/
-Tyler
Other related posts:
