linux-kernel - Re: [PATCH] UTC timestamp option for FAT filesystems

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <48630286.2050006@skyrush.com>
Date:	Wed, 25 Jun 2008 20:44:22 -0600
From:	Joe Peterson <joe@...rush.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] UTC timestamp option for FAT filesystems

Joe Peterson wrote:
>> Also even if it worked it seems very limited. If you do that why not
>> have an option to set an arbitary time zone offset?
> 
> Yes, I thought about also providing an option that lets the user specify the
> offset at mount - this may be useful for other scenarios (like moving Windows
> disks between time zones), but the UTC option, itself, is very useful in that it
> let's one use UTC on FAT devices, which is the least problematic way to do
> things (e.g. for digital cameras, etc.).

After thinking about this some more, I actually do not see much point in
allowing an arbitrary offset on FAT.  Only two modes make sense: local
time (current default) and UTC (new proposed option).  Here's the
reason: in "local time" mode (the default in Linux and Windows), a FAT
filesystem records just that to the disk: local time.  For example, on
Windows, it doesn't matter which time zone is in use; a file written at
12:00 will still show a time of 12:00 even if the time zone is changed
on the system.  If a user with a Windows laptop travels around, changing
the time zone, files saved at noon in one time zone will appear to have
the same time when in another.  This does not make sense in a "real
time" sense (it would be possible, for example, to have a file written
later but with an earlier timestamp if the user crosses a time zone
boundary to the west (and sets the time zone) just before saving the
second file).  Such a typical traveling Windows user will have files
saved in many different time zones, so there would be no meaning to
setting an arbitrary time zone offset when mounting such a volume.  The
files on the volume would just have to considered stamped in "local
time", wherever the user happened to be.

Linux's implementation of FAT "local time" mode does this as well.  It
simply adds to a timestamp exactly what the userland level will subtract
when displaying the time, making that timestamp appear as it is
numerically on the disk, in local time.

So FAT filesystem timestamps make sense in one of two modes for a given
volume: local time or UTC.  The former handles volumes used under
Windows well, and the latter would be extremely useful for other devices
which use FAT filesystems but need to have a more sensible "real" time
format (like, as I pointed out, digital cameras).

						-Joe
--
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/