Wrong timestamps on FAT32 partitions

[Yiannis Dondos]

When I mount a FAT32 partition, many files appear to have wrong timestamps. Specifically, during the winter months (Standard Time) all files modified in summer appear having their timestamps shifted by +1 hour. During the summer months (when Daylight Savings is in effect) these files have correct timestamps, but all the winter files have their timestamps shifted by -1 hour!

When observing the same files under WinXP or Win98, timestamps always appear the same.

The VFAT driver of Linux should not modify the timestamps, depending on whether DST is in effect or not. The driver should respect the timestamps of the FAT32 partition. FAT32 stores timestamps according to the local wall-clock time, not UTC, so there is absolutely no need for conversions.

This problem causes rsync to copy hundreds of files from FAT32 to EXT3 partitions, twice a year, without any reason.

Thank you for your precious time!

ProblemType: Bug
Architecture: i386
CurrentDmesg:
 [ 30.652222] r8169: eth0: link up
 [ 30.652227] r8169: eth0: link up
 [ 41.160007] eth0: no IPv6 routers present
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=3cb64f18-eadd-4088-a233-e77650fbcce5
MachineType: MICRO-STAR INTERNATIONAL CO.,LTD MS-7519
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-19-generic 2.6.28-19.61
ProcCmdLine: root=UUID=5220bc1b-b6d8-4b61-a6cc-bb5cd4609375 ro quiet splash vga=794
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-19.61-generic
SourcePackage: linux

[Yiannis Dondos (dondos)]

These two links are related to this report:
http://lwn.net/Articles/287428/ (this is a very useful patch, but does not solve the problem I report)
http://<email address hidden>/msg134178.html (a proposed patch, never implemented, looks like it could be the solution)

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Yiannis Dondos (dondos)]

This is a duplicate of Bug#25048.

[Jarno Suni (jarnos)]

The bug exists in 13.10 release.

[Jarno Suni (jarnos)]

I was running rsync simulation from Meego's (= the linux OS of my Nokia N9) vfat partition to Ubuntu 13.10's linux partition yesterday (after the clocks had been moved) and it was telling it is going to copy all the "summer" files that seemed to be 1 hour newer. I did not do full run based on modification times, but added --size-only option to prevent re-copying the files with the same content. Oddly, when I looked at the local files and remote files (connected as vfat mass storage by USB) on Ubuntu today, I saw no difference between the timestamps of both directories. I played with time and date settings of both Ubuntu and Meego, but I could not reproduce the difference between times on either, when viewed in Ubuntu. However, the modification times look correct only when viewing within Meego (e.g. in terminal). When I view in Ubuntu, the modification times are 2 hours too old regardles of whether they are modified on summer time or winter time. (Here in Finland timezone is +3 during summer time and +2 during winter time.) I am confused.

[Jarno Suni (jarnos)]

I simulated rsync to a third location, and again the old files on destination were an hour older.
I did a backup to a third location using a command (updating based on file size):
rsync -r -t -o -v --progress --size-only -u /media/data/ /media/jarno/red_iomega/data/
After that, the following simulation does not suggest any file for updating:
rsync -r -n -t -o -v --progress -u /media/data/ /media/jarno/red_iomega/data/
i.e. the modification times are equal. So it seems like the rsync command updates the modification times on destination, propably due the -t option, even if sizes are equal and --size-only is used.