Bug 802198 - Incorrect timestamps for VFAT
Incorrect timestamps for VFAT
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-11 22:52 EDT by Danny Ciarniello
Modified: 2012-10-12 12:46 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-07 18:48:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Danny Ciarniello 2012-03-11 22:52:07 EDT
Description of problem:
Timestamps for files on a VFAT-formatted flash card (such as one used in a digital camera) are mounted with UTC time rather than local time.

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
Mount a VFAT-formatted card (without tz option)
  
Actual results:
The file timestamps are displayed in UTC

Expected results:
The file timestamps should be in local time 

Additional info:

The mount man page states

"tz=UTC This  option  disables  the conversion of timestamps between local time (as used by Windows on FAT) and UTC (which Linux uses internally).  This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time."

This would imply that no conversions should be done if the tz option is not specified.  I. e. timestamps should be in local time.

Note that this worked as expected in Fedora 14.
Comment 1 Karel Zak 2012-03-26 05:28:41 EDT
(In reply to comment #0)
> The mount man page states
> 
> "tz=UTC This  option  disables  the conversion of timestamps between local time
> (as used by Windows on FAT) and UTC (which Linux uses internally).  This is
> particularly useful when mounting devices (like digital cameras) that are set
> to UTC in order to avoid the pitfalls of local time."
> 
> This would imply that no conversions should be done if the tz option is not
> specified.  I. e. timestamps should be in local time.
> 
> Note that this worked as expected in Fedora 14.

Hmm... sounds like kernel timezone is not set properly. Reassigning to systemd.
Comment 2 Michal Schmidt 2012-03-26 08:00:35 EDT
I see. fat.ko cares about sys_tz.

sys_tz is set by settimeofday(). systemd calls it once on boot only if the hardware clock is running in local time. The purpose of the call is to do the clock warp (a correction from local time to UTC).
We don't want to do the warp when the clock is in UTC. This report shows that we should however set sys_tz. So the solution for the !hwclock_is_localtime case could be to call settimeofday() twice:
First with tz.tz_minuteswest=0 in order to do a dummy warp (a NOP).
Second with the actual correct tz_minuteswest value to set sys_tz.

Is your RTC clock running in UTC? (What does the 3rd line in /etc/adjtime say?)
Comment 3 Danny Ciarniello 2012-03-26 11:28:52 EDT
Yes, my RTC clock is set to UTC.
Comment 4 Karel Zak 2012-03-27 06:35:44 EDT
Michal, see also bug #672194 ;-)
Comment 6 Lennart Poettering 2012-09-17 11:29:45 EDT
Kay, please set bugs that are fixed upstream but not yet fixed in Fedora to POST!
Comment 7 Fedora Update System 2012-09-20 15:56:33 EDT
systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18
Comment 8 Fedora Update System 2012-09-22 02:37:41 EDT
Package systemd-191-2.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-191-2.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-191-2.fc18
then log in and leave karma (feedback).
Comment 9 Danny Ciarniello 2012-09-23 23:04:51 EDT
Is the fix going to be pushed to Fedora 17 as well?
Comment 10 Fedora Update System 2012-09-27 20:18:11 EDT
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2012-10-01 16:10:49 EDT
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2012-10-12 12:46:22 EDT
systemd-44-20.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-20.fc17

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