[Samba] WinXP/x64 - MFC CFile objects leak parent directory handles

[Dragan Krnic]

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?