cd9660 largefile fix

[Csaba Henk]

On 2006-02-15, Csaba Henk <csaba.henk at xxxxxxx> wrote:
> 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

OK, then the official stuff:

http://www.ecma-international.org/publications/files/ecma-st/ECMA-119.pdf

7.3 32 - bit numerical values
[...]
7.3.3 Both-byte orders
      A numerical value represented by the hexadecimal representation
      (st uv wx yz) shall be recorded in an eight-byte
      field as (yz wx uv st st uv wx yz).

[...]

9 File and Directory Descriptors
[...]
9.1.4 Data Length (BP 11 to 18)
      This field shall specify as a 32-bit number the data length of the File Section.
      This field shall be recorded according to 7.3.3.

Sort of funny though that the Wikipedia entry which led me there was
equipped with the warning "but please be careful because it has several
small incompatibilities with real-life iso images".

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

Just to make it clear, by "first two" I meant the first two of the three
enumerated alternatives, not "first two bytes" or anything like that.

Regards,
Csaba