modtime not preserved on copying onto samba share - got the

[Andrej Borsenkow]

> -----Original Message-----
> From: samba-technical at samba.anu.edu.au
> [mailto:samba-technical at samba.anu.edu.au]On Behalf Of Luke Kenneth
> Casson Leighton
> Sent: Saturday, October 10, 1998 2:15 AM
> To: Multiple recipients of list
> Subject: Re: modtime not preserved on copying onto samba share - got the
>
>
> this is probably why NT caches file times for approx 30 seconds.  you can
> delete a file and recreate it within 30 seconds and it will retain the
> (create, i think) time of the previous file.
>
> this was discussed on ntbugtraq a couple of months ago.
>
>  On Sat, 10 Oct 1998, Andrej Borsenkow wrote:
>
> > O.K. I got it. The sequence is as following:
> >
> > NT create & X
> > SMBwrite - wites 0 bytes *at the end of file* (creating empty file)
> > transact2 set file info -
> > transact2 set file info - one of them (dunno) correctly sets file times
> > SMBwrite - writes the rest of file, thus resetting all file times :((
> >
> > nice shot
> >
> > looks, call_trans2setfilepathinfo() should just remeber passed
> a/mtimes.And
> > whatever is called, when write is complete, should set them (SMBclose?)
> >
>



Hmm ... Is it possible for SAMBA to set flag "we don't preserve times on
write" or "we don't cache attributes" or like? I think, caching attributes
in smbd is too far fetching.

I compared traces NT-NT and NT-SAMBA. The main differences are

 - NT-NT is sending many Change Notify requests;

 - the following is from NT-SAMBA traces:

Frirst transact2 Set File Info:

          SMB: T2 I/O Flags Summary = 3784 (0xEC8)
              SMB: ..........0..... = Allow write-behind on file
              SMB: .........1...... = Do not allow caching of this file

Second transact2 Set File info:

          SMB: T2 I/O Flags Summary = 3 (0x3)
              SMB: ..........0..... = Allow write-behind on file
              SMB: .........0...... = Allow caching of this file

Suddenly, NT insists on caching the result of second frame. I believe, there
*must* be some flag (probably, as response to NTcreateX?), that will disable
attr. caching. Both transact2 Set File info frames on NT-NT traces say
"caching not allowed" in this case. 'course, this caching may have nothing
to do with the problem ...

Another possibility is these change notify. May be, if we send "file was
changed" after finished writing, NT will set correct times?

/andrej