On 25 Jan 00 at 19:18, Oleg Makarenko wrote:
> > You have to have per-mountpoint function
> > (ioctl) which allows you to pass pre-parsed timezone data into kernel.
> > Server uses its own local time, not yours.
> Are you completly sure on that? I always thought Netware server uses UTC time
> for files when it talks to the clients.
> Am I wrong?
It uses its localtime. If it used UTC, you do not have to play these
stupid plays, as whole kernel thinks in UTC.
> But then if the server really uses my local time as you say why at all does
^^^ its own
> my local timezone setting matter?
Whole problem is caused by DOS/Windows, which expects that server is using
localtime, so you have to adjust for that. Unfortunately, for NW older than
4.0 it was possible to say that server runs in UTC and DOS clients are broken.
But with NW4/NW5, which knowns what UTC time is, you cannot say such
thing anymore - NCP protocol uses server localtime and now you have written
it down black on white by Novell.
> If say I change ncpfs to ignore sys_tz completely I see all times in UTC
> while my server thinks it is in MSK zone.
When server creates file, it assigns current server time as ctime/mtime/atime
to that file (and atime is handled by server completely). So you have
to have some relation between UTC and server localtime. And there is no
way to find such relation, except asking server what's the time just now...
> If you are right and the server uses its own local time (not UTC) when it
> talks to the clients then where does this UTC time that is converted in
> fs/ncpfs/dir.c/utc2local() come from?
utc2local is used when time is transmitted to server. Otherwise
local2utc is used, for example in inode.c:ncp_update_inode2 ->
-> dir.c:dos2unix -> dir.c:local2utc
> As I see it the server uses UTC time and the client (ncpfs) incorrectly
> transfers it to my local time (correct me if I am wrong).
If I do
touch remote/asd
umount remote
mount remote
ls -l remote/asd
I'll get back correct time. Unfortunately, for some unknown reason when
I have TZ=CET, kernel's tz_minuteswest is -120 instead of correct -60
(correct me if I'm wrong...), so although I see correct 18:06 from Linux,
DOS WS see 19:06. If you have lanalyzer, you can see that reply returned
to create from server contains 18:06 - altough GMT is 17:06, so returned
time is local, not UTC.
> > currently I have mounted three ncpfs volumes, from different timezones.
> > Timestamps are wrong on all that filesystems, as expected...
> If I simultaniously create two files on two file servers that are in
> different timezones then what timestamps should I have?
> Hope you agree they should be the same, shouldn't they?
They are same from your point of view, but time really stored on server
in one zone will be way different from another server. Face it, these
times are local to server, they are neither UTC nor your local workstation
time.
> If you agree with me
> and I am right with my assumption that server uses UTC when
> it speaks to client then I don't have to have per mount ioctl, do I?
But your assumption is wrong.
> > I will not
> > accept any timestamp patch to ncpfs except one which correctly handles
> > files created in past/future too, because of although current situation is
> > not perfect, it is how things works for some years now...
> With the current hwclock code when DST becomes active sys_tz doesn't change
> at all and that is why I have wrong times for new files on ncpfs.
There is no way. There was proposed couple of times fix to change tz_dsttime
meaning from meaningless DST_NONE/DST_USA/DST_AUST... to something
more meaningful, like current offset between localtime and GMT or
between localtime and GMT+tz_minuteswest.
> If Andries fixes hwclock so that kernel sys_tz does reflect the currect
> active dst then while the time of newly created file is correct the
> time of previously created files suddenly changes by one hour. That is why
> I think ncpfs code should be fixed too. The wrong time is
> probably even better than that sudden file times change but the things
> currently work only due to the bug in hwclock!
Currently times are constant and correct from Linux view. If I find whether
ntpd4 or who sets tz_minuteswest incorrectly (btw it is debian-woody), times
will match to DOS workstations during non-DST time.
> Summarizing,
> 1. We need sys_tz to have correct values. That means Andrea need to fix
> hwclock. That is probably done already.
OK.
> 2. If sys_tz is correct and reflects active dst and has correct
> tz_menutestowest value than all files on ncpfs
> (and probaly on other file systems?) suddenly change their times twice per
vfat... maybe smbfs
> year with the simle +/- tz_menutestowest*60 math
> and that is definitly wrong.
This behavior of ncpfs was there before...
> 3. To fix that we need at least dststart and dstend somewhere in the kernel
> but struct timezone that is used in settimeofday() doesn't have
> these fields. So hwclock and kernel need to use some other structure and
> probably some other syscall. The question is what structure and
> what syscall.
Simple structure... glibc parses TZ data to array of 68 (2038-1970) pairs
containing each year start DST and end DST. If you want to be really perfect,
you can change it to 2*68 pairs of {tz_offset, start_date} as I heard that
there is some timezone which has three steps during year...
> 4. If I understand you right You say that even that is not enough cause
> Novell servers use their own timezones and to makes things
> work I need to store their dststart dstend somewhere too. (please
> confirm)
Yes. If you want cross-timezones mounts correctly. They are incorrect now
and noone complains...
> But as you see 1-3 is unrelated to 4. It possible to fix 1-3 and change
> utc2local() to use new structure instead of sys_tz so that it could calculate
> local time from utc correctly. Does that break anything?
I hope no. But if you decide to implement (4), you do not have to implement
syscall for (3)...
> The other question
> is how difficult is to write correct utc2local() code in kernel.
> Does that mean porting of all Olsen's timezone code into kernel? I don't
> think so. Only small parts of it as all initialization can be done in
> hwclock. With the assumption that dst rules are stable themselves it is as
> simple as having global dststart and dstend fields somewhere in the kernel
> and do some math in utc2local().
It is simple loop (off by one errors possible):
/* tzarray is part of superblock when filesystem does not use
UTC... */
struct { unsigned int start; int tz_offset; } tzarray[500] =
{ 0, -60 }, /* before 1978 there was no DST here in our country */
{ 30.3.1978 01:00, -120 }, /* ... */
{ 29.9.1978 00:00, -60 }, /* ... */
...
{ 0xFFFFFFFF, -60 } /* last region */
for (ent = tzarray+1; time_to_convert > tzarray->start; tzarray++);
converted_time = (--tzarray)->tz_offset;
> If you are right and Netware servers do really use their local times when
> talking to the clients than somebody should go further
> and modify ncpfs to create one new_timezone structure per connection (through
> ioctl as you suggest) and then write new server2utc() function that uses it.
> But we still need something other than struct timezone to make that function
> work correctly. And we still need global utc2local().
Probably function name is misleading. Both utc2local & local2utc functions
in ncpfs should be named utc2server & server2utc, as converting time from
UTC back to localtime is task for your glibc.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:15 EST