https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082006-02-16T01:15:20ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #93: cd9660 largefile fixhttps://bugs.dragonflybsd.org/issues/93?journal_id=3082006-02-16T01:15:20Zcorecode
<ul></ul><p>Csaba Henk wrote:</p>
<blockquote>
<p>Hi,</p>
<p>Sizes are stored in a signed type for the cd9660 fs, hence we can't<br />see >= 2G files. This is an old BSDism, and as I checked, it's been<br />weeded out from (or never existed in) other OSS Unices, except for<br />FreeBSD.</p>
</blockquote>
<p>why wouldn't we use uint64_t's? otherwise there is the same problem for <br />4GB files, or does iso9660 not support files > 32bits anyways?</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #93: cd9660 largefile fixhttps://bugs.dragonflybsd.org/issues/93?journal_id=3092006-02-16T01:49:10Zcsaba.henk
<ul></ul><p>On 2006-02-15, Simon 'corecode' Schubert <<a class="email" href="mailto:corecode@fs.ei.tum.de">corecode@fs.ei.tum.de</a>> wrote:</p>
<blockquote>
<p>why wouldn't we use uint64_t's? otherwise there is the same problem for <br />4GB files, or does iso9660 not support files > 32bits anyways?</p>
</blockquote>
<p>It seems that a standard-compliant iso9660 fs would have both bytes<br />filled so that the value can be directly used both on little and big<br />endian archs.</p>
<p>That is, the actual information is just one byte large. I can imagine<br />that some iso9660 creator tool ignores this and utilizes all 64 bits;<br />vanilla mkisofs won't do this, and breaks on >= 4G files.</p>
<p>Cf. the following (unofficial) info:</p>
<p><a class="external" href="http://article.gmane.org/gmane.os.netbsd.current/21055">http://article.gmane.org/gmane.os.netbsd.current/21055</a></p>
<p>If it's a concern, maybe we should add mount opts to read this data<br />field as a 32 bit value, to read it as a 64 bit le value or read it as a<br />64 bit be value. (Or at least the first two -- that's how Linux does<br />[although they seem to think that the upper byte is either the tail of a<br /> > 4G value or "cruft"].)</p>
<p>Regards,<br />Csaba</p> DragonFlyBSD - Bug #93: cd9660 largefile fixhttps://bugs.dragonflybsd.org/issues/93?journal_id=3102006-02-16T16:38:20Zcsaba.henk
<ul></ul><p>On 2006-02-15, Csaba Henk <<a class="email" href="mailto:csaba.henk@creo.hu">csaba.henk@creo.hu</a>> wrote:</p>
<blockquote>
<p>On 2006-02-15, Simon 'corecode' Schubert <<a class="email" href="mailto:corecode@fs.ei.tum.de">corecode@fs.ei.tum.de</a>> wrote:</p>
<blockquote>
<p>why wouldn't we use uint64_t's? otherwise there is the same problem for <br />4GB files, or does iso9660 not support files > 32bits anyways?</p>
</blockquote>
<p>It seems that a standard-compliant iso9660 fs would have both bytes<br />filled so that the value can be directly used both on little and big<br />endian archs.</p>
<p>That is, the actual information is just one byte large. I can imagine<br />that some iso9660 creator tool ignores this and utilizes all 64 bits;<br />vanilla mkisofs won't do this, and breaks on >= 4G files.</p>
<p>Cf. the following (unofficial) info:</p>
<p><a class="external" href="http://article.gmane.org/gmane.os.netbsd.current/21055">http://article.gmane.org/gmane.os.netbsd.current/21055</a></p>
</blockquote>
<p>OK, then the official stuff:</p>
<p><a class="external" href="http://www.ecma-international.org/publications/files/ecma-st/ECMA-119.pdf">http://www.ecma-international.org/publications/files/ecma-st/ECMA-119.pdf</a></p>
<p>7.3 32 - bit numerical values<br />[...]<br />7.3.3 Both-byte orders<br /> A numerical value represented by the hexadecimal representation<br /> (st uv wx yz) shall be recorded in an eight-byte<br /> field as (yz wx uv st st uv wx yz).</p>
<p>[...]</p>
<p>9 File and Directory Descriptors<br />[...]<br />9.1.4 Data Length (BP 11 to 18)<br /> This field shall specify as a 32-bit number the data length of the File Section.<br /> This field shall be recorded according to 7.3.3.</p>
<p>Sort of funny though that the Wikipedia entry which led me there was<br />equipped with the warning "but please be careful because it has several<br />small incompatibilities with real-life iso images".</p>
<blockquote>
<p>If it's a concern, maybe we should add mount opts to read this data<br />field as a 32 bit value, to read it as a 64 bit le value or read it as a<br />64 bit be value. (Or at least the first two -- that's how Linux does<br />[although they seem to think that the upper byte is either the tail of a</p>
<blockquote>
<p>4G value or "cruft"].)</p>
</blockquote></blockquote>
<p>Just to make it clear, by "first two" I meant the first two of the three<br />enumerated alternatives, not "first two bytes" or anything like that.</p>
<p>Regards,<br />Csaba</p> DragonFlyBSD - Bug #93: cd9660 largefile fixhttps://bugs.dragonflybsd.org/issues/93?journal_id=3312006-02-27T10:58:10Zcorecode
<ul></ul><p>Csaba Henk wrote:</p>
<blockquote>
<p>Hi,</p>
<p>Sizes are stored in a signed type for the cd9660 fs, hence we can't<br />see >= 2G files. This is an old BSDism, and as I checked, it's been<br />weeded out from (or never existed in) other OSS Unices, except for<br />FreeBSD.</p>
</blockquote>
<p>committed, thanks!</p>