Linux-kernel mailing list archive 2000-04,: Re: bug: wrong file times on ncpfs

# Re: bug: wrong file times on ncpfs

Guest section DW (dwguest@win.tue.nl)
Tue, 25 Jan 2000 15:43:02 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Richard B. Johnson: "Re: Corruption caused by umount not flushing the buffer cache."
- Previous message: Anton Ivanov: "Re: "Clock Skew detected error""

On Tue, Jan 25, 2000 at 09:58:57AM +0300, Oleg Makarenko wrote:

> The problem: All file times on Novell server are one hour older then
> they really are. (RH6.x,no matter what 2.2 kernel. The timezone settings
> do really matter and the time is wrong for any timezone that has DST but
> DST is NOT active)

Yes.

Several years ago I wrote in settimeofday.2:

The use of the timezone struct is obsolete; the tz_dsttime
field has never been used under Linux - it has not been
and will not be supported by libc or glibc. Each and
every occurrence of this field in the kernel source (other
than the declaration) is a bug. Thus, the following is
purely of historic interest.

The field tz_dsttime contains a symbolic constant (values
are given below) that indicates in which part of the year
stant throughout the year - it does not indicate that DST
is in force, it just selects an algorithm.)

The author of hwclock didnt believe me and tried to use "daylight"
anyway, as if it indicated that DST is in force now. But it doesnt,
so this fails. Since I maintain hwclock these days, I removed this
code from hwclock 2.10e as released a few days ago.

Similarly, many kernel authors are deluded and one finds
./linux/fs/fat/misc.c: if (sys_tz.tz_dsttime) secs -= 3600;
./linux/fs/fat/misc.c: if (sys_tz.tz_dsttime) unix_date += 3600;
./linux/fs/hpfs/hpfs_fn.h: return t + sys_tz.tz_minuteswest * 60
- (sys_tz.tz_dsttime ? 3600 : 0) + ...
./linux/fs/udf/udftime.c: offset = (-sys_tz.tz_minuteswest
+ (sys_tz.tz_dsttime ? 60 : 0));
as if tz_dsttime indicated that DST is in force now.
All these occurrences are bugs, and life is simplified when every
fragment like `+ (sys_tz.tz_dsttime ? 60 : 0)' is deleted from
kernel source. Maybe I should construct a patch.

[The hfs author does the right thing in hfs_sysdep.h]

Does this solve all problems? No - I think it is impossible to solve
this problem in the kernel. If timestamps on some filesystems are
in localtime, and the kernel does not have all of Olsens timezone
code, then it cannot convert this to UTC and back. (And close to the
moment of change this isnt even a 1-1 function. So, mirror software
will always have difficulties close to the change of DST if the
filesystem uses localtime.)

The problem comes up every now and then; some months ago there was
an extensive discussion. I mainly answer now to make people aware
of the fact that the hwclock behaviour changed. Some incorrect code
was removed. I may well be convinced to add some correct code instead,
adapting tz_minuteswest under suitable circumstances.

Andries

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

- Next message: Richard B. Johnson: "Re: Corruption caused by umount not flushing the buffer cache."
- Previous message: Anton Ivanov: "Re: "Clock Skew detected error""