Hello, sorry for slow response.
(I have lost and found your first letter.)
On Tue, 28 Nov 2000, Urban Widmark wrote:
> On Fri, 24 Nov 2000, Igor Yu. Zhbanov wrote:
>
...
>
> > I have found a bug in drivers of file systems which use a DOS-like format
> > of date (16 bit: years since 1980 - 7 bits, month - 4 bits, day - 5 bits).
>
> [snip]
>
> > 2) VFAT for example have three kinds of dates: creation date, modification date
> > and access date. Sometimes one of these dates is set to zero (which indicates
> > that this date is not set). Zero is not a valid date (e.g. months are
> > numbered from one, not from zero) and can't be properly converted to
> > UNIX-like format of date (it was converted to date before 1980).
>
> Days are also numbered from one (at least smbfs) and this change doesn't
> do anything about that. An all zero date gives 315446400 (or else my
> testprogram is broken) and you wanted it to give 315532800 (?). So that
> should be fixed too, I think.
I think your testprogram is broken (or else my testprogram is broken :). After applying
my pathch you will get 315532800 (86400*(-1+3653)) on zero date (Jan 1 GMT 00:00:00
1980).
Since 'month = ((date >> 5) & 15) - 1;' is changed to 'month = ((date >> 5) - 1) & 15;'
variable 'month' will be equal to 15 (on zero date) instead of -1. Since day_n[15]==0
you
will get 315532800 (Jan 1 GMT 00:00:00 1980). So nothing to be fixed, I think.
I hope FAT filesystem will be fixed too some day :)
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
