ISO9660 bug and loopback driver bug

ISO9660 bug and loopback driver bug

[Barubary]

First, the ISO9660 bug.  The ISO file system driver in Linux doesn't handle
leap years correctly.  It assumes all years divisible by 4 are leap years,
which is incorrect.  For those that don't know the right algorithm, all
years that (are divisible by 4) and ((not divisible by 100), or (divisible
by 400)) are leap years.  ISO file dates on or after March 1, 2100 will be 1
day off when viewed under Linux as a result.  The bug is in fs/isofs/util.c,
function iso_date().  This is a very low priority bug, because a) nobody
cares about ISO file date accuracy including me; and b) it shouldn't matter
until 2100.  Anyone bored enough to fix this? :)  I guess I could do it...

Now the loopback bug.  Files whose size is greater than 2^31-1 don't work
with the loopback driver.  It fails with strange errors, like "device not
found".  This bug prevents DVD-ROM .iso files from being mounted as either
UDF or ISO file systems - the particular use I encountered it with.  It's a
bit higher of a priority than the ISO9660 date bug, because it prevents
useful features from working.  Still not too important though.

The above were encountered on 2.4.17, and are both in 2.4.18.

-- Barubary

Re: ISO9660 bug and loopback driver bug

[Jesper Juhl]

On Tue, 2002-02-26 at 12:37, Barubary wrote:
> First, the ISO9660 bug.  The ISO file system driver in Linux doesn't handle
> leap years correctly.  It assumes all years divisible by 4 are leap years,
> which is incorrect.  For those that don't know the right algorithm, all
> years that (are divisible by 4) and ((not divisible by 100), or (divisible
> by 400)) are leap years.  ISO file dates on or after March 1, 2100 will be 1
> day off when viewed under Linux as a result.  The bug is in fs/isofs/util.c,
> function iso_date().  This is a very low priority bug, because a) nobody
> cares about ISO file date accuracy including me; and b) it shouldn't matter
> until 2100.  Anyone bored enough to fix this? :)  I guess I could do it...
> 

I'll fix it. I'm still learning about the kernel, and fixing small bugs
is a good way to learn - and this one is on a scale I can handle. :-)

I'll look at it tonight and mail a patch to lkml as soon as the work is
done.


> Now the loopback bug.  Files whose size is greater than 2^31-1 don't work
> with the loopback driver.  It fails with strange errors, like "device not
> found".  This bug prevents DVD-ROM .iso files from being mounted as either
> UDF or ISO file systems - the particular use I encountered it with.  It's a
> bit higher of a priority than the ISO9660 date bug, because it prevents
> useful features from working.  Still not too important though.
> 

I'll give this one a shot as well, but I'm not yet sure I'm up to it -
will have to look at the code first. :)


-- 
Mvh. / Best regards
Jesper Juhl - jju@dif.dk

Re: ISO9660 bug and loopback driver bug

[Rainer Ellinger]

Barubary wrote:

> Now the loopback bug.  Files whose size is greater than 2^31-1 don't work
> with the loopback driver.

Can't reproduce. I can mount 4.7GB DVD-Images and i'm currently working with an 48GB File mounted via loop, and a 100GB partition 
mounted via loop. I'm using loop-AES encryption patch with 2.4.17/18-rc4. I'm not aware if there's a fix in this patch. afaik it 
should also work with vanilla loop.c.

-- 
rainer@ellinger.de

Re: ISO9660 bug and loopback driver bug

[Barubary]

Can you try a file between 2^31 and 2^32-1, inclusive?  Maybe it's a
sign-related bug in the loopback driver, not a 64 bit I/O bug.

The file I tried to mount is this on an NTFS partition:

12/10/2001  20:13     3,522,562,048 dvd.iso

"losetup" fails too, meaning it's the loopback driver (and possibly the NTFS
driver) that is glitching, not the ISO driver.

Maybe trying to mount *anything* from an NTFS driver doesn't work?  I'll
have to check that possibility too...

-- Barubary

----- Original Message -----
From: "Rainer Ellinger" <rainer@ellinger.de>
To: "Barubary" <barubary@cox.net>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, February 26, 2002 4:01 AM
Subject: Re: ISO9660 bug and loopback driver bug


> Barubary wrote:
>
> > Now the loopback bug.  Files whose size is greater than 2^31-1 don't
work
> > with the loopback driver.
>
> Can't reproduce. I can mount 4.7GB DVD-Images and i'm currently working
with an 48GB File mounted via loop, and a 100GB partition
> mounted via loop. I'm using loop-AES encryption patch with 2.4.17/18-rc4.
I'm not aware if there's a fix in this patch. afaik it
> should also work with vanilla loop.c.
>
> --
> rainer@ellinger.de
>
>

Change that to an NTFS bug not loopback

[Barubary]

I tried to mount a 20 meg ISO from an NTFS partition mounted read-only and
it glitched.  It has nothing to do with the size of the file.  I would've
checked smaller files if I had mkisofs handy, which I didn't when I tried
it.

Now I'm afraid that it's a known bug and I've wasted your time... :(

-- Barubary

Re: Change that to an NTFS bug not loopback

[Richard Russon]

Hi Barubary,

> I tried to mount a 20 meg ISO from an NTFS partition mounted read-only and
> it glitched.  It has nothing to do with the size of the file.  I would've
> checked smaller files if I had mkisofs handy, which I didn't when I tried
> it.

Reading through the thread, I've just tried everything you have.
I've used 2.4.18-rc4.  I've first mounted an NTFS partition.  Within
that I've mounted

1a)  Another NTFS partition (from a device)       1Gb   (< 2^31 bytes)
1b)  Another NTFS partition (from a device)       2.2Gb (> 2^31 bytes)
2)   Another NTFS partition (from a loop device)  2.2Gb (> 2^31 bytes)
3)   An ISO image (from a loop device)            20Mb  (< 2^31 bytes)

Please can you clarify what's going wrong.  I can't seem to get the
NTFS driver to go wrong.

If I can repeat the problem, I can probably fix it.

> Now I'm afraid that it's a known bug and I've wasted your time... :(

Don't worry.  If something doesn't work, someone here will want to hear
about it (and fix it).

Cheers,
  FlatCap (Rich)
  ntfs@flatcap.org

P.S.  Anton's on holiday (current NTFS maintainer), so you've got me :-)

Re: ISO9660 bug and loopback driver bug

[Alan Cox]

> which is incorrect.  For those that don't know the right algorithm, all
> years that (are divisible by 4) and ((not divisible by 100), or (divisible
> by 400)) are leap years.  ISO file dates on or after March 1, 2100 will be 1

Thats actually locale dependant, but yes. I'll fix that one.

> Now the loopback bug.  Files whose size is greater than 2^31-1 don't work
> with the loopback driver.  It fails with strange errors, like "device not
> found".  This bug prevents DVD-ROM .iso files from being mounted as either

The loopback driver isnt 64bit file I/O aware afaik. That might be trickier
to fix.

Re: ISO9660 bug and loopback driver bug

[Barubary]

> Thats actually locale dependant, but yes. I'll fix that one.

Why is it locale-dependent?  All ISO9660 file times are stored as Gregorian
calendar dates regardless of who made them, and the target (UNIX file time)
isn't locale-dependent either.  Why would it affect the calculation if the
local system used the Muslim calendar?

You're probably right, but I just want to know why so I'll know for the
future.

Shouldn't there be a gregorian_date_to_unix_time() function in the kernel so
that every driver that needs such conversion can share that implementation?
It would keep date processing consistent and make it easy to spot date bugs.

-- Barubary

Re: ISO9660 bug and loopback driver bug

[Alan Cox]

> Why is it locale-dependent?  All ISO9660 file times are stored as Gregorian
> calendar dates regardless of who made them, and the target (UNIX file time)

Thanks - I wasn't aware it was always defined to be the gregorian calendar
in ISO9660. The orthodox calendar differs in computation (its more accurate)
and the two actually diverge in 2800. (Pan Orthodox congress 1923 if anyone
actually cares)

> isn't locale-dependent either.  Why would it affect the calculation if the
> local system used the Muslim calendar?

Unix file time is clean of those problems 

> Shouldn't there be a gregorian_date_to_unix_time() function in the kernel so
> that every driver that needs such conversion can share that implementation?
> It would keep date processing consistent and make it easy to spot date bugs.

Not a bad idea if there are enough file systems doing it.