[openbeosstorage] Re: ISO9660/cdrom progress
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 21 Feb 2003 00:24:35 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > On the volume, well that could be. They usually store all directory
> > data session-locally, and refer to the data volume-globally.
> Yes. Unless I've missed something, only directory records can address
> data of another volume. Thus in fact only file contents from other
> volumes can be referenced. Subdirectory in theory as well, but, since
> they also need to have a path table record, which provides volume
> local
> addressing only, this is not possible.
Well, I would just ignore those :-)
[...]
> > The fifth session would contain the whole directory tree and has
> > pointers to the file data on disk.
> I think, we are not really disagreeing. Of course in practice it
> doesn't make much sense to be able to select more than one former
> volume as a start point for the new directory hierarchy. But since
> the
> new volume will store its own directory hierarchy, it is impossible
> to
> say on which former one it is based originally. E.g. if you burn a
> second volume based on the first one without changing anything, and
> for
> the third volume start with the directory hierarchy of the second
> one,
> in the end there will be no reference to the second volume on it; the
> directory hierarchy will be cloned and the file data from the first
> volume are pointed to directly.
>
> So, while I believe, that it is true, that when following the usage
> pattern of Nero or any other of those applications, the volumes are
> created tree-like, I also think, that when considering the data on
> the
> disk, there will be no trace of this. As said earlier, the only thing
> one could reconstruct (by analyzing the FS) is, the file data of
> which
> volumes are reused.
Exactly, that's basically what I tried to sell you as a different
opinion ;-))
> > Indeed, it should be as flexible and open as possible. But of
> > course,
> > it should support the "standard" as completely and transparent as
> > possible.
> I believe, my proposed extension will provide that well enough. :-)
Very nice :-)
Adios...
Axel.
Other related posts:
