RESENDING: NT vs Samba file timestamp issue

[Paul Heinz]

Jeremy wrote:
> Paul Heinz wrote:
> >
> > We also have the problem of the timestamp being set via the
> > trans2::SMB_SET_FILE_BASIC_INFO  call being incorrect when
> performing simple
> > NT COPY commands or copying via Explorer.
>
> What *exactly* do you mean by "incorrect". What time values
> are being stored in which timestamp. What I need is what timestamp
> values are stored on the NT client, and what you expect to see
> on the Samba server, and what you do see.

Ok. When the server isn't busy, I'll turn back on nt smb support and collect
some specific examples for you. Until then, I can tell you what we
originally observed in case that helps.

Initially, we noticed that when copying a file from NT onto the Samba server
that the modtime timestamp was showing a date portion 1 day earlier than it
should with a seemingly unrelated (to the source modtime) time portion which
was back in the past.

Exploring the problem, we changed the source file on NT (updating the source
modtime) and retried the copy and the _same_ altered modtime showed up. We
tried copying other files and noticed the same problem - each file would get
it's own erroneous modtime.

> > We have applied the MIN vs MAX patch that was mentioned on the
> Samba digest
> > but this does not appear to fix the problem, rather it just
> gives different
> > wrong results.
>
> Can you be more specific please. The MIN vs. MAX change fixed
> the issues brought up by at least one Samba admin.

Yes, I'll collect some actual data for you.

To continue the above saga, I checked the samba list and search for
mtime/atime messages, thus seeing the MIN vs MAX post. We then applied said
patch which seemed to solve the original COPY problem.

I then saw what I thought were further modtime corruptions across COPY but
(from memory), the dates were now on the same day for the date portion, but
the time portion was incorrect and in the future. Perhaps I was seeing an
accesstime being stored as a modtime? I'm not sure.

So I turned off nt smb support and the problem modtimes vanished. At this
stage, I could have been mistaken in what I thought I saw - it was a month
or two ago now.

> > The timestamp code in trans2.c looks like a pretty complex code
> path with
> > the MIN/MAX, pending_modtime and NIL timestamp workarounds and I'm left
> > wondering if the correct timestamp to apply at pending_modtime is not
> > getting 'lost'...
>
> I need more info on what you expect to happen before I
> can look for the bug.

Yes, I know what it's like trying to track down bugs in complex code without
specifics :-) My apologies. I'll see what I can do to reproduce the problem
that the MIN/MAX patch doesn't seem to fix to make sure it's really there
and to offer some actual examples.

Is there any particular level of Samba logging you would like to see as part
of my testcases, Jeremy?

TTFN,
  Paul.