cd9660 largefile fix

[Csaba Henk]

On 2006-02-15, Simon 'corecode' Schubert <corecode at xxxxxxxxxxxx> wrote:
> why wouldn't we use uint64_t's?  otherwise there is the same problem for 
> 4GB files, or does iso9660 not support files > 32bits anyways?

It seems that a standard-compliant iso9660 fs would have both bytes
filled so that the value can be directly used both on little and big
endian archs.

That is, the actual information is just one byte large. I can imagine
that some iso9660 creator tool ignores this and utilizes all 64 bits;
vanilla mkisofs won't do this, and breaks on >= 4G files.

Cf. the following (unofficial) info:

http://article.gmane.org/gmane.os.netbsd.current/21055

If it's a concern, maybe we should add mount opts to read this data
field as a 32 bit value, to read it as a 64 bit le value or read it as a
64 bit be value. (Or at least the first two -- that's how Linux does
[although they seem to think that the upper byte is either the tail of a
 > 4G value or "cruft"].)

Regards,
Csaba