DragonFlyBSD

Csaba Henk wrote:

Hi,

Sizes are stored in a signed type for the cd9660 fs, hence we can't
see >= 2G files. This is an old BSDism, and as I checked, it's been
weeded out from (or never existed in) other OSS Unices, except for
FreeBSD.

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?

cheers
simon

On 2006-02-15, Simon 'corecode' Schubert <corecode@fs.ei.tum.de> 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

On 2006-02-15, Csaba Henk <csaba.henk@creo.hu> wrote:

On 2006-02-15, Simon 'corecode' Schubert <corecode@fs.ei.tum.de> 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

Csaba Henk wrote:

Hi,

Sizes are stored in a signed type for the cd9660 fs, hence we can't
see >= 2G files. This is an old BSDism, and as I checked, it's been
weeded out from (or never existed in) other OSS Unices, except for
FreeBSD.

committed, thanks!