Samba 3.0.28-0.1.95-1624-SUSE-SL10.3
A strange problem (best read in a proportional font).
It only happens on an x64 XP client when accessing
a Samba share. The exact same program runs fine
on the same x64 XP client when the share accessed
is on a Windows server or when it is run on a 32-bit
XP client, regardless of whether the share belongs to
a Samba server or to a Windows server.
I have traced the problem to a local instantiation of an
object of MFC class CFile in the line 170 of the following
code:
166 CString CWaitForChangedFile::GetFileContent()
167 { if (mstrFilePath.IsEmpty())
168 return "";
169 _my_TRY
170 CFile file(mstrFilePath,
CFile::modeRead |
CFile::shareDenyNone);
171 int size = (int)file.GetLength();
172 CString text;
173 file.Close();
174 text.Format("%d", size);
175 return text;
176 _my_REPORT_EXCEPTION_ALL
177 return "ERROR!!!!!";
178 }
When the programm using this method is run on a
Windows XP Professional x64 Edition and a file
"mstrFilePath" is opened for read with an oplock
of type "DenyNone" on a Samba share, as above
in line 170, a new handle to the parent directory
remains stuck until the program is stopped, which
should actually be removed when the program exits
the method. The handle looks something like this
in the output of "handle.exe -a -p thisProg.exe":
46C: File (RWD) \Device\LanmanRedirector\;X:0000000000014c30\samba\T01\
On the Linux side (SuSE 10.3, kernel 2.6.22.13-0.3-default)
I can trace this behaviour to the fact that the transactions in
the lines 39 through 60 in the following formatted audit log
don't appear when the programm is run on an x64 XP, which
DO get executed when the program is run on a 32-bit XP
(the lines following the "getxattr" of "user.DOSATTRIB"
after setting the "kernel_flock" on the already opened file).
1 stat T01/T01.ini
2 getxattr T01/T01.ini:user.DOSATTRIB
3 THE PREVIOUS 2 LINES REPEATED 14 TIMES
4 stat .
5 stat T01
6 getxattr No data T01|user.DOSATTRIB
7 stat T01/T01.ini
8 opendir T01
9 stat T01/T01.ini
10 stat T01/T01.ini
11 sys_acl_get_file T01/T01.ini
12 getxattr No data T01/T01.ini:user.SAMBA_PAI
13 sys_acl_get_entry
14 sys_acl_get_tag_type
15 sys_acl_get_permset
16 sys_acl_get_perm
17 sys_acl_get_perm
18 sys_acl_get_entry
19 sys_acl_get_tag_type
20 sys_acl_get_permset
21 sys_acl_get_perm
22 sys_acl_get_perm
23 sys_acl_get_entry
24 sys_acl_get_tag_type
25 sys_acl_get_permset
26 sys_acl_get_perm
27 sys_acl_get_perm
28 sys_acl_get_entry
29 sys_acl_free_acl
30 fget_nt_acl T01/T01.ini
31 getxattr T01/T01.ini:user.DOSATTRIB
32 closedir
33 stat T01/T01.ini
34 stat T01
35 getxattr T01/T01.ini:user.DOSATTRIB
36 open r T01/T01.ini
37 kernel_flock T01/T01.ini
38 getxattr T01/T01.ini:user.DOSATTRIB
39 *************** stat T01/T01.ini
40 sys_acl_get_file T01/T01.ini
41 getxattr No data T01/T01.ini:user.SAMBA_PAI
42 sys_acl_get_entry
43 sys_acl_get_tag_type
44 sys_acl_get_permset
45 sys_acl_get_perm
46 sys_acl_get_perm
47 sys_acl_get_entry
48 sys_acl_get_tag_type
49 sys_acl_get_permset
50 sys_acl_get_perm
51 sys_acl_get_perm
52 sys_acl_get_entry
53 sys_acl_get_tag_type
54 sys_acl_get_permset
55 sys_acl_get_perm
56 sys_acl_get_perm
57 sys_acl_get_entry
58 sys_acl_free_acl
59 get_nt_acl T01/T01.ini
60 ************** fstat T01/T01.ini
61 getxattr T01/T01.ini:user.DOSATTRIB
62 fstat T01/T01.ini
63 sendfile T01/T01.ini
I guess that Samba sends the same information in response
to a "getxattr" no matter what the bitness of the client is.
So it's probably the client SMB code on x64 XP which is
doing something in a different way when it finds out that the
share belongs to a Samba server.
No combination of oplock settings makes any difference.
Does anyone know how to avoid this problem?
Should I provide some more diagnostics?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
