I tried the smbfs patch you posted today. It did cure the problem on
first write operation after WfW starts, with the expected log entry:
Nov 22 19:13:41 cy kernel: smb_newconn: server not locked, count=1
Nov 22 19:13:41 cy kernel: smb_offerconn: server not locked, count=1
Nov 22 19:13:41 cy kernel: smb_offerconn: state valid, pid=317
Nov 22 19:13:51 cy kernel: smb_create: fileid 0??
Nov 22 19:14:30 cy kernel: smb_request_ok: rcls=1, err=18 mapped to 0
Nov 22 19:14:42 cy kernel: smb_errno: class ERRDOS, code 50 from command 9
No error messages from the application.
*****************************************************
Odd behavior with both NT Workstation 4.0 (alpha) and WfW:
There seems to be a problem with the client not becoming aware of newly
added files on directory scans:
- Create a file on the server side:
C:\>echo > wintest
and it shows up when listed there (naturally).
- At the same time, the client is logged to the same directory. It does
not show "wintest" on a mass directory lookup:
Script started on Sat Nov 22 19:45:49 1997
(hirsch@cy) ~ : cd /tmp/smb/TEMP
(hirsch@cy) /tmp/smb/TEMP : dir
total 5
drwxr-xr-x 1 hirsch system 512 Oct 19 1939 MSE000/
-rwxr-xr-x 1 hirsch system 3650 Oct 28 1905 msoF.tmp*
(hirsch@cy) /tmp/smb/TEMP : dir
total 5
drwxr-xr-x 1 hirsch system 512 Oct 19 1939 MSE000/
-rwxr-xr-x 1 hirsch system 3650 Oct 28 1905 msoF.tmp*
(hirsch@cy) /tmp/smb/TEMP : ls dir wintest
-rwxr-xr-x 1 hirsch system 13 Jan 25 1955 wintest*
(hirsch@cy) /tmp/smb/TEMP : dir wintest
-rwxr-xr-x 1 hirsch system 13 Jan 25 1955 wintest*
^^^^^^^^^^^^
But, note that it does show up when specifically stat-ed.
Back to directory operations:
(hirsch@cy) /tmp/smb/TEMP : dir
total 5
drwxr-xr-x 1 hirsch system 512 Oct 19 1939 MSE000/
-rwxr-xr-x 1 hirsch system 3650 Oct 28 1905 msoF.tmp*
(hirsch@cy) /tmp/smb/TEMP : cd
Finally, after I cd back to home and list from there:
(hirsch@cy) ~ : dir /tmp/smb/TEMP
total 6
drwxr-xr-x 1 hirsch system 512 Oct 19 1939 MSE000/
-rwxr-xr-x 1 hirsch system 3650 Oct 28 1905 msoF.tmp*
-rwxr-xr-x 1 hirsch system 13 Jan 25 1955 wintest*
(hirsch@cy) ~ : dir /tmp/smb/TEMP
total 6
drwxr-xr-x 1 hirsch system 512 Oct 19 1939 MSE000/
-rwxr-xr-x 1 hirsch system 3650 Oct 28 1905 msoF.tmp*
-rwxr-xr-x 1 hirsch system 13 Jan 25 1955 wintest*
(hirsch@cy) ~ : exit
Script done on Sat Nov 22 19:47:00 1997
Strange, eh? WfW behaves the same way; the file is not detected until you
cd out of the mount point and try an ls from there. From that point on,
it shows up fine from all points.
**************************************************
Timestamps & NT Workstation 4.0 Shares:
You will note that the file timestamps above are bizarre. I tried to
quantify what is going on, but the biases between machines are not even
repeatable, much less quantifiable <g>.
Create a file on the NT server, and it shows as Nov 22, 1997.
List it from the client? It's Apr 5, 2012.
>From client:
$ touch /tmp/smb/TEMP/wintest
On the client it shows as Feb 26, 1979.
On the server it is correct; or Nov 22, 1997.
>From client:
$ touch /tmp/linux1
$ cp /tmp/linux1 /tmp/smb/TEMP
From the client this shows up as Apr 12, 2015.
$ cp /tmp/linux1 /tmp/smb/TEMP
Do the same thing again. The copied file now shows Jan 29, 1926!
As you can see, the offsets are random.
****************************************************************
Timestamps & WfW 3.11 Shares:
Everything works as you'd expect, except for the fact that Unix files
copied to the share display with the date they were moved there. I would
much prefer it if they'd appear with their Unix mtime after copying.
At one point, smbfs did work that way. Was there a conscious decision to
alter the semantics?
Steve