#9524 closed bug (fixed)
[iso9660, fat and exfat fs add-ons] time convercion mistakes
Reported by: | beos_zealot | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | File Systems | Version: | R1/Development |
Keywords: | timezone gmt | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Explanation:
"ConvertRecDate" function converts time stored in iso9660 fs to time_t. The time of files/dirs is stored in iso9660 fs as localtime (meaning that timezone offset from GMT is allready included), so we have not to add "tz" value to "time", but subtract it to get a true GMT time (what we use internally).
Example:
The action takes place in Lithuania, so my timezone is GMT+2. For testing pusposes i touch'ed file and wrote it to iso9660 image. Time mismatch between touch'ed file (11:56) and file in iso image (15:56) is +4 hours (see attached picture: time-calculation_before-patch.jpg).
After enabling trace and adding additional debug lines i got this info: timezone offset "tz" value of file in iso image is 8, it means 8 intervals of 15min from GMT, that's (8*15)/60 = 2 hours = GMT+2 (so it's correct).
It happens that 2 hour time offset is added twice:
1) "ConvertRecDate" function adds +2 hours (tz=8) while converting time to time_t value (iso9660.cpp line 1005) 2) and +2 hours added when this time_t value gets converted to localtime when file is showed in Tracker (takes system's timezone settings into account = Lithuania GMT+2)
So 11:56 -> 13:56 -> 15:56.
If we subtract 2 hours (tz=8) while converting time in step 1) - everything returns to its place (see attached picture: time-calculation_after-patch.jpeg).
Then 11:56 -> 09:56 (GMT time) -> 11:56.
Patch attached.
P.S. it appears that this computing error is very old and has been fixed in other posix OS'es:
1994 in NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/isofs/Attic/isofs_node.c.diff?r1=1.10&r2=1.11&hideattic=0&only_with_tag=MAIN&f=h
1994 in FreeBSD: http://svnweb.freebsd.org/csrg/sys/isofs/cd9660/cd9660_node.c?r1=67376&r2=67375&pathrev=67376
1996 in Linux: https://www.kernel.org/pub/linux/kernel/v2.1/patch-2.1.32.bz2 (lines 3039-3099)
Attachments (9)
Change History (19)
by , 12 years ago
Attachment: | time-calculation_before-patch.jpeg added |
---|
by , 12 years ago
Attachment: | time-calculation_after-patch.jpeg added |
---|
by , 12 years ago
Attachment: | 0001-iso9660-fs-add-on-time-convertion-mistake-fix.patch added |
---|
comment:1 by , 12 years ago
patch: | 0 → 1 |
---|
comment:2 by , 12 years ago
comment:4 by , 12 years ago
Quick test showed that on my system time difference between file real creation time and time readings from fat32 fs also +4, so yes, seems like a similar problem.
Ok, I'll look into it.
by , 12 years ago
Attachment: | 1_fat32_fs_windows_gmt+2.jpg added |
---|
by , 12 years ago
Attachment: | 2_fat32_fs_haiku_gmt+2_before-patch.jpeg added |
---|
by , 12 years ago
Attachment: | 3_fat32_fs_haiku_gmt+2_after-patch.jpeg added |
---|
by , 12 years ago
Attachment: | 4_fat32_fs_windows_gmt+2_OK.jpg added |
---|
by , 12 years ago
Attachment: | 0001-iso9660-fat-and-exfat-fs-add-ons-corrects-time-conve.patch added |
---|
comment:5 by , 12 years ago
It appears that FAT and also EXFAT fs add-on have the same problem.
[FAT fs] The time of files/dirs is stored in FAT fs as localtime (*1), so: 1) when we read timpestamps from FAT fs we have to subtract timezone offset ("tzoffset" value) in "dos2time_t" function to get rawtime (it will be used internally as intermediate data). 2) when we write timestamps to FAT fs we have to add timezone offset ("tzoffset" value) in "time_t2dos" function to the rawtime to make it localtime (it will be directly written to fs).
[EXFAT fs] The time of files/dirs is stored in EXFAT fs as localtime (*2), so when we read timpestamps from EXFAT fs we have to subtract timezone offset ("tzoffset" value) in "_GetTimespec" function to get rawtime (it will be used internally as intermediate data).
*1)http://msdn.microsoft.com/en-us/library/ms724290.aspx (second paragraph) *2)http://www.sans.org/reading_room/whitepapers/forensics/rss/reverse_engineering_the_microsoft_exfat_file_system_33274 (page 39). Actually EXFAT also has optional UTC timestamp support, but it's not implemented in our fs add-on
Attached new common patch for all three fs add-ons, because patch is small and it fixes the same problem, so i think it's not necessary to make separate tickets+patches for each fs add-on.
P.S. Could anybody (with admin rights) edit ticket - add appropriate additional components and change name to: [iso9660 fs add-on] time convertion mistake -> [iso9660, fat and exfat fs add-ons] time convertion mistakes Thanks in advance :)
comment:6 by , 12 years ago
Component: | File Systems/ISO 9660 → File Systems |
---|---|
Summary: | [iso9660 fs add-on] time convertion mistake → [iso9660, fat and exfat fs add-ons] time convercion mistakes |
comment:7 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Applied in hrev45668. Thanks!
Could you also check with an exfat FS in several Windows versions? I did compared timestamps in Linux and in Haiku and there is still one hour off in Linux... might be a Linux bug though.
comment:8 by , 11 years ago
Ok, i'll try to check exfat FS in several Windows versions during the next week.
One hour off in Linux? The first idea that comes to my head without tests - maybe it related to exfat UTC support and DST adjustments.
by , 11 years ago
Attachment: | files-written-to-EXFAT-on-winXP-and-Win7.jpeg added |
---|
comment:9 by , 11 years ago
USB flash stick was formatted to exFAT file system on Windows 7. Test files were written to exFAT on Windows 7 and Windows XP. Timestamp readings from exFAT on Haiku are correct (view attached screenshot above).
If time permits i would like to check also on other OS'es...
Patch looks okay to me but can someone more experienced look into this one?