On Tue, 7 Dec 2004, Rhialto wrote:

> On Thu 02 Dec 2004 at 00:02:15 -0600, Frederick Bruckman wrote:
>> Suppose we just assume that partial blocks won't occur in the middle of a
>> file?
>
> That sounds like an excellent idea. So, when cd9660 encounters the
> multiple directory entries belonging to the same file, it could/should
> check for internal partial blocks and round up (so the total size
> matches with the added internal junk).

Yes, that's what I was thinking, rounding up to 2K blocks, leaving 
garbage in the middle where necessary. It's not like there many level 
3 images to be found in the wild. The only reason I brought it up, is 
that it's a way to be able to represent arbitrarily large files on ISO 
9660 images.

The ideas presented in the ISO 9660 spec were ahead of their time. You 
were supposed to be able to create different files from different cuts 
of the same data -- think "deleted scenes" or "director's cut". Level 
3 was never widely implemented, and the so the DVD-Video folks 
evidently decided to do the same thing at a higher level. Now, while 
the spec apparently also allows for partial blocks in the middle of a 
file, I can't see any purpose to creating such a file, and I believe 
it must be a defect in the spec. What we would have then, would be 
technically a partial implementation of ISO 9660 Level 3, but so what?

> Alternatively, if there are internal partial blocks, it could handle the
> file as it is now (whatever that happens to be, show only a partial file
> maybe), or even more alternatively it could even show multiple files
> with some derived name for each.  Depending on the application this
> might even be not completely useless.

I think, now, that that's just too complicated. You can already see 
the "raw" directory entries with a tool such as "isoinfo", and knowing 
that file sections must be continuous extents, you could extract them 
with "dd" (or "isoinfo").  There's no need to expose internals to the 
file system.

What NetBSD does *now* -- listing only the tail end of the file -- is 
maximally dumb.  If only it got the start right, but the length wrong, 
that would be better. ("mplayer" would just work, as it appears to 
ignore the file length in favor of the information in the VOB.)

> Of course one might also implement UDF, but a quick Google session does
> not yet reveal some source code to drop in. There is
> http://sourceforge.net/projects/linux-udf/ though.

I'd be surprised if that were useful to NetBSD.  UDF is a more evolved 
version of ISO 9660 (with new directory structures), and the specs are 
already public. Besides, as you might expect, linux-udf is GPL'd.


Frederick