bug: wrong file times on ncpfs

[Oleg Makarenko]

Petr Vandrovec wrote:

> On 25 Jan 2000 Oleg Makarenko wrote:
> > correct shift value in its local2utc()/utc2local() functions I still
> > have some anomalies: on DST the time of previously created files will be
> [snip]
> > I don't see how can I change ncpfs either :( cause to make it calculate
> > local times correctly I need the values of dststart and dstend for local
> > timezone and can't find the needed structure in the kernel and the way
> > to initialize it.
> > While it is possible to add needed structure and new syscall somebody on
> > the list should know the better solution.
> It is not completely correct.

Sure it is not right way to fix things. That is why I ask for others opinion.

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

But then if the server really uses my local time as you say why at all does
my local  timezone setting matter?
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.

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?

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

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

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

Summarizing,

1. We need sys_tz to have correct values. That means Andrea need to fix
hwclock. That is probably done already.
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
year with the simle +/- tz_menutestowest*60 math
   and that is definitly wrong.
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.
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)

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

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

Best regards,
Oleg






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/