Summary: | FAT32 - Time stamp of file is one hour off | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Erik Nordstrøm <erik> | ||||
Component: | bin | Assignee: | Pedro F. Giffuni <pfg> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | cem, dab, damjan.jov, kib, pfg | ||||
Priority: | --- | ||||||
Version: | 11.0-RELEASE | ||||||
Hardware: | amd64 | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Erik Nordstrøm
2017-03-05 11:14:08 UTC
Image was about half of a megabyte too big to be attached. You can download a copy of the ~1.5MiB file from https://www.nordstroem.no/blob/7e/bc/32e9d7c-1534776.img If I'm not mistaken, the FAT file system stores timestamps in local time. When that FAT file system is mounted in a Unix-like system (e.g., FreeBSD), the timestamp is interpreted as if it is UTC; that system cannot know what the timezone was on the system that wrote the FAT file system. So, since you are +1:00 from UTC, you see the timestamp one hour in the future. (In reply to David Bright from comment #2) The discussion above presumes that your PlayStation 4 actually records the time as an MS-DOS/Windows system does. I don't know if that is actually the case. There is definitely some timestamp bug here. In my UTC+2 timezone: $ date Sun Apr 29 03:23:58 SAST 2018 $ touch bsd-201804290323.txt $ stat -x bsd-201804290323.txt File: "bsd-201804290323.txt" Size: 0 FileType: Regular File Mode: (0755/-rwxr-xr-x) Uid: ( 1002/ user) Gid: ( 0/ wheel) Device: 0,139 Inode: 59620 Links: 1 Access: Sun Apr 29 02:00:00 2018 Modify: Sun Apr 29 05:23:58 2018 Change: Sun Apr 29 05:23:58 2018 Windows shows the correct modified/changed times of 03:23. Why is FreeBSD adding my time zone offset (2 hours) to the times when stat reads them, even though they are already in local time? Created attachment 192889 [details]
Use vfs_timestamp() instead of getnanotime() in msdosfs
I've noticed msdosfs uses getnanotime() to generate timestamps, unlike ufs, ext2fs, devfs, nandfs, nfsclient, nfsserver, and tmpfs, which all use the better vfs_timestamp() function instead (which allows filesystem timestamp granularity to be configured using the vfs.timestamp_precision sysctl). Only autofs and msdosfs use getnanotime().
Patching msdosfs to use vfs_timestamp() instead, seems to also fix this bug here, with msdosfs timestamps having the timezone offset added to them a second time when read.
Please find my patch attached.
(In reply to Damjan Jovanovic from comment #5) Change to use vfs_timestamp() should be fine by itself, but I cannot see how could it solve 'off by a hour' issue. (In reply to Konstantin Belousov from comment #6) By default vfs.timestamp_precision is TSP_USEC, which returns microtime() instead of getnanotime(). The timezone for microtime() seems to be more correct than for getnanotime(). (In reply to Damjan Jovanovic from comment #7) This does not make sense, there is no 'timezone', and esp. there is no 'more correct' timezone. The difference between e.g. getmicrotime() and microtime() is that get return current clock hands without quering hardware to get the most precise possible value for the timecounter. So the typical precision of of getXXX() is 1/hz, while precision of XXX() is around the precision of hardware. But both variants return UTC time as known by kernel. (In reply to Konstantin Belousov from comment #8) Thank you, I'll try that test again with a clean kernel rebuild. MICROTIME(9) does not document the timezone for the time functions. (In reply to Damjan Jovanovic from comment #9) Something must have been wrong with my setup. With a clean kernel rebuild, I can no longer reproduce this bug, even without my patch. Sorry. That patch may still be worth committing regardless ;). (In reply to Damjan Jovanovic from comment #10) Did you tweaked machdep.adjkerntz or machdep.wall_cmos_clock between tests ? (In reply to Konstantin Belousov from comment #11) During my early tests, I did change CMOS clock to local time in the BIOS, and run tzsetup selecting that the CMOS clock is in local time, but I still got the same bad times after that. Most probably, between experimenting with several patches to the msdosfs code that passed utc=1 to fattime2timespec() and/or timespec2fattime(), and sometimes forgetting to run "make installkernel" after "make buildkernel", I ended up with a badly patched msdosfs binary, that kept giving bad times until I did a clean rebuild. Commits base r333311 (-current) and base r334742 (MFC to stable/11) applied the suggested patch (or similar). Can this bug now be closed? Added pfg@ (who committed the change) to CC List to get his input on this question, too. (In reply to David Bright from comment #13) The patch was committed but it is unrelated the bug, and that's why the PR was not mentioned in the commit. I think the issue might have been related to an update of the timezone database though. Can one of the affected users confirm the bug is gone? Comment on attachment 192889 [details]
Use vfs_timestamp() instead of getnanotime() in msdosfs
Obsolete the patch as it was committed in r333311 and MFCd to 11/stable.
^Triage: apparently committed to all supported branches. CLose the issue since there was no reply on the issue reappearing. |