Hi,
I'm an ex kernel developer, writing to you because of a problem with
FAT and its Linux driver.
When re-rsync'ing two hard drives (one VFAT, one NTFS mounted with
ntfs-3g) after a Daylight Saving Time change (I was on CEST, +0200,
now I'm on CET, +0100), I discovered a one-hour time difference over
all files (on FAT, they are one hour in future).
My current understanding is that FAT stores times relative to the
current timezone, and that's crappy (see fat_time_fat2unix(), in
fs/fat/misc.c). But with the current code, it gets even more crappy -
the same file will have a different _UTC_ timestamp depending on my
current timezone, since the current offset from UTC is added to the
stored timestamp to get the UTC time (I verified the timezone change
would perfectly explain, even in sign, the time difference I found).
That's why I guess that the FAT timestamps are wrong.
I frankly doubt that Windows is so bad.
On DOS, they could get away without any conversion at all. But on
current Windows systems? Either you find the right time zone at file
saving time (too complicated IMHO) or ignore DST when saving/restoring
time (i.e. pretend DST is not in effect, and add the shift if needed).
I don't know right now what happens.
I wrote this mail to discuss what would be the correct solution (the
second?), and if it is possible to implement it.
Thanks for your attention
Regards
--
Paolo Giarrusso
Paolo Giarrusso <[email protected]> writes:
> When re-rsync'ing two hard drives (one VFAT, one NTFS mounted with
> ntfs-3g) after a Daylight Saving Time change (I was on CEST, +0200,
> now I'm on CET, +0100), I discovered a one-hour time difference over
> all files (on FAT, they are one hour in future).
> My current understanding is that FAT stores times relative to the
> current timezone, and that's crappy (see fat_time_fat2unix(), in
> fs/fat/misc.c). But with the current code, it gets even more crappy -
> the same file will have a different _UTC_ timestamp depending on my
> current timezone, since the current offset from UTC is added to the
> stored timestamp to get the UTC time (I verified the timezone change
> would perfectly explain, even in sign, the time difference I found).
> That's why I guess that the FAT timestamps are wrong.
> I frankly doubt that Windows is so bad.
>
> On DOS, they could get away without any conversion at all. But on
> current Windows systems? Either you find the right time zone at file
> saving time (too complicated IMHO) or ignore DST when saving/restoring
> time (i.e. pretend DST is not in effect, and add the shift if needed).
> I don't know right now what happens.
> I wrote this mail to discuss what would be the correct solution (the
> second?), and if it is possible to implement it.
fat_time_{fat2unix,unix2fat}() doesn't handle timezone correctly. It
just uses timeoffset from sys_tz.tz_minuteswest. But, it is not enough
for localtime. Because it doesn't handle DST or such complex stuff. (As
workaround, fat has "tz=UTC" option)
To get correct conversion, those functions have to handle timezone
database (zoneinfo or something).
I think the issues would be, who (userland or kernel) handle zoneinfo,
and how handle.
Well, so, FWIW, I was thinking make timezone subsystem. userland app
pass one of zoneinfo to kernel as data via ioctl or sysfs or something
with name, and subsystem manages the lifetime/etc. of data. And
provide utc2local(time, zone name) to convert time correctly.
So, fs would be able to get help of utc2local() to convert to on-disk
format, and probably, zonename will be specified as mount option.
Thanks.
--
OGAWA Hirofumi <[email protected]>