From: Jesper Juhl <jju@dif.dk>
To: barubary@cox.net, alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
Subject: Re: ISO9660 bug and loopback driver bug - a bigger problem then it would appear?
Date: Wed, 27 Feb 2002 00:17:43 +0100 [thread overview]
Message-ID: <3C7C1797.7050604@dif.dk> (raw)
> 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,
Ok, unless I'm missing something (quite possible), this bug cannot be
fixed without lots of changes outside fs/isofs/util.c .
First of all, the function returns "int", so ints being 4 bytes, this
function can not handle dates beyond ~2038. And since there are no leap
years between 1970 and 2038 that are not correctly accounted for by just
doing a divide by four (the year 2000 would have been the only exception
due to the if year%100 == 0 then it's not a leap year rule, but it is
after all due to the year%400 exception to that rule).
There is also the problem of the function only being passed a single
char as the value for the year - that's not enough to be able to pass
the year 2100, and it's only beyond this year that we have a problem
with the current code. In order to be able to pass more than a single
char to iso_date() we'd have to modify the "struct iso_directory_record"
structure to extend the "date" field to be able to hold the entire four
digit year that iso9660 actually stores on disk (if I'm not mistaken) -
changing that struct would then require that all users of the struct be
checked for correctness. That's quite a large piece of work, and it's
pointless as long as iso_date just returns "int".
Is the above analysis correct or did I miss something obvious?
If the above is indeed correct, wouldn't it then be better to just do
those changes in 2.5.x instead of 2.4.x (and then maybe backport them
later)...
Comments ?
Best regards,
Jesper Juhl
jju@dif.dk
next reply other threads:[~2002-02-26 23:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-26 23:17 Jesper Juhl [this message]
2002-02-27 14:29 ` ISO9660 bug and loopback driver bug - a bigger problem then it would appear? Richard B. Johnson
2002-02-27 16:54 ` Jesper Juhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C7C1797.7050604@dif.dk \
--to=jju@dif.dk \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=barubary@cox.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.