[openbeosstorage] Re: ISO9660/cdrom progress
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 20 Feb 2003 15:51:48 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> 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).
On the volume, well that could be. They usually store all directory
data session-locally, and refer to the data volume-globally.
[...]
> > 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.
> So, Axel has seen trees where there weren't any=3F Oh, oh,... ;-)
I had seen a forest, at least ;-))
> * 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.
Right, one volume never is represented by a tree, but the whole volume/
session hierarchy of a disk can.
> * 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, this structure is in general a DAG. E.g. in
> Axel's
> example one could add a 5th session reusing files from sessions 3 and
> 4
> (given that those sessions mean volumes).
That's not completely correct, I think. Of course, the 5th session
could reuse files from session 3 and 4, but it will only import the
directory data from one session, so it can only contain files that are
part of both sessions. At least this is what all burn applications that
I know allow to do.
The fifth session would contain the whole directory tree and has
pointers to the file data on disk.
> 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).
Something like this would be nice, yes.
> 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.
Indeed, it should be as flexible and open as possible. But of course,
it should support the "standard" as completely and transparent as
possible.
> The interface for the disk=5Fscanner modules would need to be adjusted
> in
> any case. I will think about this.
Thanks!
Adios...
Axel.
Other related posts:
