Re: Bug in fat-fs code: file date/time wrong

Peter Daum (gator@cs.tu-berlin.de)
Sat, 13 Nov 1999 13:52:43 +0100 (MET)


On Sat, 13 Nov 1999, Edgar Toernig wrote:

> Peter Daum wrote:
> >
> > it seems, that the calculation of fat/vfat file times in the
> > linux kernel is incorrect. Consider the following DOS directory
> > listing:
> >
> > jan 0 01-01-1999 0:00
> > feb 0 02-01-1999 0:00
> > mar 0 03-01-1999 0:00
> > apr 0 04-01-1999 0:00
> >...
> > date/time as MS-DOS. When mounted as a msdos or vfat file system,
> > Linux reports the following timestamps instead:
> >
> > FILENAME MTIME
> > jan 98-12-31 23:00
> > feb 99-01-31 23:00
> > mar 99-02-28 23:00
> > apr 99-04-01 00:00
> >...
>
> Afaics fat uses wall clock time. To convert it to linux's
> GMT time you have to know the DST state of the date to convert.
> But figuring out if DST was in effect at that date is a very
> complicated thing and, I guess, will never be put into the
> kernel. The method to use the current DST state is a simple
> solution that'll work most of the time.
>
> Unfortunately, the tz_dsttime field does not indicate if DST
> is in effect but just says that DST "applies during some part
> of the year". The value of tz_dsttime defines which DST rule
> should be used. (This is similar to libc's "daylight" var.)
>
> A quick userspace hack that would give you correct results for
> the current DST interval would be to call settimeofday and set
> tz_dsttime to 1 if DST is in effect and to 0 otherwise. Afaics
> only fat and iso9660 use this field and both wrong.

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'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.

- 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).

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.

Unfortunately, this would mean that a user level program would
have to find out what kind of file system a file is on (and of
course, what OS - maybe even what OS version - it is running on)
in order to know how to interpret file dates. Probably the only
way to get a consistent behavior independent of the file system
type would require the kernel to figure out the DST settings for
timestamps on such file-systems - certainly pretty ugly, but
maybe still preferable...

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 ...

Regards,
Peter

-- 
                                             __o  
     Peter Daum <gator at cs.tu-berlin.de> _'\<_ 
       - pgp messages welcome -       ____(_)/(_)

- 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/