Re: ISO9660/cdrom progress

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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.