Messages in this thread | | | Date | Sun, 14 Nov 1999 03:49:37 +0100 | From | Edgar Toernig <> | Subject | Re: Bug in fat-fs code: file date/time wrong |
| |
Peter Daum wrote: > [bogus handling of time fields in fat snipped] > > I looked into the kernel sources a little deeper and found the > following: > > - sys_tz.tz_dsttime never seems to be set to anything. As far as > I can tell, it's value is always zero, no matter what date is > set.
It is modified by settimeofday (kernel/time.c:do_sys_settimeofday). And, if you look at this function you'll notice that it additionally adjusts the kernel's clock the first time it is called to handle rtcs running with local time.
> - It's value is used in fat iso and hpfs file systems. > > - the intended semantics of "sys_tz.tz_dsttime" are somewhat > unclear. A comment in "include/linux/time.h" simply says > "minutes west of Greenwich". It seems natural (particularly > since there is another field "tz_dsttime") to assume, that > this contains the offset to UTC _with no DST setting in > effect_. It's usage in the sources is usually consistent with > that view. On the other hand, hfs for example depends on > tz_minuteswest containing the _current_ offset to UTC.
I guess the semantics should be similar to the two variables timezone and daylight in libc. That is, timezone holds the offset without DST correction and daylight contains a value != 0 to specify that DST is sometimes in effect. Note though, that struct timeval is different: tm_gmtoffs (present in glibc) always contains the offset including DST and tm_isdst says that DST is currently in effect.
> - the actual value at least on my machine (linux 2.2.13/glic > 2.0.7) is alway 120, no matter whether or not DST is currently > in effect (which, together with tz_dsttime being always zero, > produces the observed effect, that timestamps on fat > file-systems are only correct for summer months).
That depends on what your rc-scripts do at startup.
> I personally don't know any good solution for this chaos. Any > kind of clearly defined behavior (like tz_minuteswest and > timestamps for files on affected file-systems always reflecting > local time or UTC and ignoring DST) would IMHO be better than the > current situation.
Unix works with UTC everywhere. Only when printing times they are converted to local time. Don't try to break this. It'll hurt.
> At least for me the whole thing is not just an academical > question but a real problem - a program (actually, a bunch of > programs) I have written just broke with the, because I had not > realized in time how unreliable file dates on fat file systems > under Linux are: The same vfat file system is (1) first written > to under Linux, (2) then under Win95, (3) then under Linux again. > With the end of DST in Europe suddenly the ctimes of all files > written in (2) appear to be an hour older than those in (1), even > though they are actually newer ...
You could add code to fat to interpret the value of tz_dsttime and add DST detection for eg DST_MET. The rules for Germany have been the same for a long time so it should be possible without too much hassle. Hint: maybe the code is already present in xBSD.
Ciao, ET.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |