Bug #93

cd9660 largefile fix

Added by csaba.henk about 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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.

As a reference, see the appropriate NetBSD commit:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/fs/cd9660/cd9660_node.h?rev=1.6&content-type=text/x-cvsweb-markup

Regards,
Csaba

--- - 2006-02-15 17:47:24.231691000 +0100
+++ vfs/isofs/cd9660/cd9660_node.h 2006-02-15 14:36:36.000000000 +0100
@@ -78,10 +78,10 @@ struct iso_node {
doff_t i_offset; /* offset of free space in directory */
ino_t i_ino; /* inode number of found directory */

- long iso_extent; /* extent of file */
- long i_size;
- long iso_start; /* actual start of data of file (may be different */
- /* from iso_extent, if file has extended attributes) */
+ unsigned long iso_extent; /* extent of file */
+ unsigned long i_size;
+ unsigned long iso_start; /* actual start of data of file (may be different */
+ /* from iso_extent, if file has extended attributes) */
ISO_RRIP_INODE inode;
};

History

#1 Updated by corecode about 8 years ago

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

#2 Updated by csaba.henk about 8 years ago

On 2006-02-15, Simon 'corecode' Schubert <> 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

#3 Updated by csaba.henk about 8 years ago

On 2006-02-15, Csaba Henk <> wrote:
> On 2006-02-15, Simon 'corecode' Schubert <> 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

#4 Updated by corecode about 8 years ago

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!

Also available in: Atom PDF