In article <20041129002051.GA16521@azenomei.knuffel.net>,
	rhialto@azenomei.knuffel.net (Rhialto) writes:
> 
> on Alpha:
> -r--r--r--   1    0    0      2149588992 Oct 30 2004 [1225476 00] FOO
> on i386:
> -r--r--r--   1    0    0      -2145378304Oct 30 2004 [1225476] FOO
> 
> since here the Alpha does get the size right it seems like the on-disk
> value is probably ok. Unless isoinfo itself always truncates the size to
> the lowest 32 bits.

ISO 9660 only permits a 32-bit number there. The field is indeed 64-bits
wide, but that's only because it's supposed to contain both the big-endian
and little-endian representations of the 32-bit data-length, back-to-back
(or face-to-face, perhaps).  If you put something else there, it's not an
ISO 9660 file system, and it's probably a bug that it works at all.

Now, ISO 9660 (level 3) does have a mechanism for larger files, but it's
not widely supported.  Simply put, consecutive directory entries with the
same name are to be taken for "file sections" of the same file. I recently
posted a patch to the cdrecord list to do the level 3 thing. Unfortunately,
NetBSD can't read such a file system correctly, but it just works with my
DVD-Video/MPEG4 hardware player, and it also happens to work with "isoinfo"
with a slight change (included):

 http://lists.berlios.de/pipermail/cdrecord-developers/2004-November/002997.html


Frederick