> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:34 EST