Bug 15567 - Incorrect timestamp written to VFAT file systems.
Incorrect timestamp written to VFAT file systems.
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Depends On:
  Show dependency treegraph
Reported: 2000-08-06 12:20 EDT by Charles Sullivan
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:38:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Charles Sullivan 2000-08-06 12:20:22 EDT
If Linux is set to use a "dual timezone", i.e., where a Standard Time
and Daylight Time are defined, then files are written to a VFAT file
system using an incorrect time during periods when Daylight Time is
in effect.  This is not evident from within Linux but becomes so when
removable VFAT media, e.g. floppy diskettes, are read on a MS-DOS PC,
or when a dual-boot system is re-booted into DOS or MS-Windows.

Example:  Two files, both created at 07:00 UTC, one in January and
the other in July, under Linux.  If Linux is set to use timezone UTC0, 
the 'ls -l --full-time' command displays:
  Sat Jan 01 07:00:00 2000 jan.txt
  Sat Jul 01 07:00:00 2000 jul.txt
and if Linux is set to use timezone EST5EDT, the same command
_correctly_ displays:
  Sat Jan 01 02:00:00 2000 jan.txt
  Sat Jul 01 03:00:00 2000 jul.txt

If both files are copied to floppy diskette using the 'cp -p' command while
timezone EST5EDT is set, Linux continues to display the correct file times 
for the copied files.  However if the floppy diskette is now transferred
to a MS-DOS PC, the file times displayed under MS-DOS are both 02:00:00,
i.e., correct for Standard Time but incorrect for Daylight Time.

MS-DOS has no notion of timezone and considers all file times to be
whatever local time was in effect.  Linux should timestamp files
written to VFAT file systems with the same times as are displayed
by 'ls -l'.

An examination of the VFAT directory time bit-field shows the time 
for both files to be identical.  The same problem also exists with other
VFAT media such as ZIP disk.

(The problem occurs with kernel version 2.2.14-5.0 as shipped with
RedHat 6.2 but also persists in kernel versions at least as late as

Note: Essentially the same problem was reported a year or so ago
while the current revision of RedHat was 5.2, but seems to have
vanished from Bugzilla - at least I can't find it.
Comment 1 Charles Sullivan 2000-08-10 00:48:33 EDT
I found my previously reported bug, number 4064.  (Bugzilla can't find it with anything other than its number.)  Its Status is listed
as "Resolved", but no resolution is shown.  As stated above the problem persists in current kernels, although slightly differently: in the
previously reported bug, the kernel created an incorrect VFAT timestamp for Standard Time while Daylight Time was correct; in the
current bug report, Standard Time is correct while Daylight Time is Incorrect. 
Comment 2 scheck 2004-04-22 09:48:25 EDT
The mount command lacks a timezone option. It uses the kernel timezone
/etc/localtime instead.

Especially with rsyncing vfat-harddisks this is very annoying, as all
files' time differ after a daylight saving change.

Workaround: set the kernel to a static timezone (e.g. GMT+6) and use
the TZ environment variable for the users. Minor drawback: log files
don't make use of DST.
Comment 3 Bugzilla owner 2004-09-30 11:38:49 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.