linux-kernel - Re: Daylight saving time & FAT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <873a4p9fvy.fsf@devron.myhome.or.jp>
Date:	Mon, 09 Nov 2009 00:48:33 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Paolo Giarrusso <p.giarrusso@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Daylight saving time & FAT

Paolo Giarrusso <p.giarrusso@...il.com> 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 <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/