[linux-cifs-client] SMB_COM_CLOSE and LastWriteTime

[Jeff Layton]

On Fri, 2 May 2008 05:54:49 +0200
Guenter Kukkukk <linux at kukkukk.com> wrote:
> I totally agree here - but when adding smbfs like legacy features -
> some additional cases have to be checked (some will be ugly enough).
> 
> Now that smbfs will be dropped completely, SOMEONE has to decide,
> whether more legacy support should be added to cifs vfs - or not!
> 
> I already spent lots of time in the past regarding more legacy 
> functionality in cifs vfs - and only a few went in.
> I really would appreciate "a definite word" how to go on.
> Steve ?
> 
> ----
> I've also setup a windows 98 box (2nd edition) - can now
> test here against the following servers:
>   - most recent samba3.0.x
>   - most recent samba3.2.x
>   - windowsXP
>   - windowsNT
>   - windows98 (2nd edition)
>   - OS/2 Warpserver and Client
>   - (MSDOS/IBMDOS - never tried that in the past)
> 
> I did lots of testing and network sniffing during the last days.
> Using my settime applet I fortunately also hit the winNT special
> case - which I remembered vaguely. The following case really
> makes sense:
> 		if (!(pTcon->ses->flags & CIFS_SES_NT4))    !!!!!!!
> 			rc = CIFSSMBSetTimes(xid, pTcon, full_path, &time_buf,
> 					     cifs_sb->local_nls,
> 					     cifs_sb->mnt_cifs_flags &
> 						CIFS_MOUNT_MAP_SPECIAL_CHR);
> 		else
> 			rc = -EOPNOTSUPP;
> 
> WindowsNT does _not_ support setPATHinfo (infolevel 257) and
> returns 0x007c0001 == NT_STATUS_INVALID_LEVEL.
> 
> So a simple utimes() - without an open file handle - would _not_
> work on winNT. In that special case open(), setFILEinfo(), close() really
> makes sense. Is already in the current code, but not in my former 
> patch - but that sequence is working and must be added!
> Same _seems_ (!) to also apply to windows98, but here in the same
> case of
>   open()
>   setFILEinfo !!!!
>   close()
> really strange stuff is happening - nonsense timestamps (year 1940, 1970)
>  .... but no error is shown (on the cmdline). I'll work on this, to explain
> it further...
> 
> For OS/2, the used setFILEinfo/setPATHinfo infolevel makes no
> sense at all - a different story.
> 

smbfs used the LastWriteTime in the close call. We may need to just
open and close the file while setting that time for these older servers.

It sounds like we will probably have 3 cases:

1) servers that understand SetPathInfo (Win2k and up, I guess). For
these, we'll use SetFileInfo if the file is already open. Otherwise,
use SetPathInfo.

2) NT4, which can use SetFileInfo. If the file isn't already open,
we'll open it first and then close it.

3) Older servers (Win9x, OS2, even older stuff). Here we'll just
open the file and close it with the LastWriteTime set. These
servers probably have coarse-grained timestamps anyway, so we aren't
likely to lose much by doing this.

> More specific info later.
> 
> I know from mailing lists and lots of irc talks, that missing
> or wrong time stamps "lead to lots of troubles in real life
> network environments" - so I vote, we should handle that
> carefully.
> 

Agreed. We want to get this right.

-- 
Jeff Layton <jlayton at redhat.com>