FreeLists / openbeosstorage / [openbeosstorage] Re: ISO9660/cdrom progress

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

> "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.

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.

> [...]
> > * 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.

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.

> > 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.

I believe, my proposed extension will provide that well enough. :-)

CU, Ingo