lkml.org 
[lkml]   [1999]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.054 / U:1.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site