samba - Aug 1999 - dptr_create: returned 9: Error - all new dirptrs in use ?

Hi,

I get this error message in the log for a Win98 client which is regularly 
scanning a directory on the share. When this happens the client no longer 
can access any data in the shares (security=share), only the toplevel 
directory structure of a share is still accessible. This seems to be a new 
problem in 2.0.5/6pre (not sure if it already happened for 2.0.4). Any hints?

Franz.

Platform: RH4.2/Intel
Log entry:
[1999/08/19 12:48:44, 0] smbd/dir.c:dptr_create(453)
   dptr_create: returned 9: Error - all new dirptrs in use ?

Server setup:
# Global parameters
[global]
         workgroup = EVERYONE
         netbios name = SHARES
         server string = Linux Samba Server
         interfaces = 10.10.10.1/24
         bind interfaces only = Yes
         security = SHARE
         encrypt passwords = Yes
         username map = /etc/smb.username.map
#       debug level = 3
         log file = /var/log/samba/%m
         max log size = 1024
         socket options = TCP_NODELAY
         preferred master = Yes
         domain master = Yes
         wins support = Yes
         kernel oplocks = No
         null passwords = Yes
[link]
         comment = Links
         path = /home/samba-mnt
         valid users = @users
         read only = No
         create mask = 010
         force create mode = 0664
         directory mask = 00
         force directory mode = 02775
         short preserve case = No
         map system = Yes

/home/samba-mnt contains mostly symbolic links to the real directories.

Uhm, this seems to be a dptr leak in combination with Win98/Win98SE. In a 
Win98  command window try "dir L:\support\mga*." (note the trailing
dot)
with "L:" being a samba-2.0.5 share and "support" a
directory with 8.3
files like "mga?????.bak", but no files like "mga?????".
You'll get
something similar to this end of the output with debuglevel=3:

[1999/08/26 16:15:06, 3] smbd/trans2.c:call_trans2findnext(882)
   call_trans2findnext: dirhandle = 267, max_data_bytes = 2432, maxentries 
= 6, close_after_request=0, close_if_end = 0 requires_resume_key = 0
resume_key = 0 resume name = mga18566.bak continue=0 level = 260
[1999/08/26 16:15:06, 3] smbd/dir.c:dptr_fetch_lanman2(545)
   fetching dirptr 267 for path support
[1999/08/26 16:15:06, 3] smbd/trans2.c:call_trans2findnext(929)
   dptr_num is 267, mask = MGA*, attr = 16, dirptr=(0x81344A0,1033)
[1999/08/26 16:15:06, 3] smbd/trans2.c:call_trans2findnext(1065)
   SMBtrans2 mask=MGA* directory=support dirtype=22 numentries=1
[1999/08/26 16:15:06, 3] smbd/process.c:process_smb(615)
   Transaction 159 of length 95
[1999/08/26 16:15:06, 3] smbd/process.c:switch_message(448)
   switch message SMBtrans2 (pid 14500)
[1999/08/26 16:15:06, 3] smbd/trans2.c:call_trans2findnext(882)
   call_trans2findnext: dirhandle = 267, max_data_bytes = 2432, maxentries 
= 6, close_after_request=0, close_if_end = 0 requires_resume_key = 0
resume_key = 0 resume name = mga18272.bak continue=0 level = 260
[1999/08/26 16:15:06, 3] smbd/dir.c:dptr_fetch_lanman2(545)
   fetching dirptr 267 for path support
[1999/08/26 16:15:06, 3] smbd/trans2.c:call_trans2findnext(929)
   dptr_num is 267, mask = MGA*, attr = 16, dirptr=(0x81344A0,1251)
[1999/08/26 16:15:06, 3] smbd/trans2.c:call_trans2findnext(1065)
   SMBtrans2 mask=MGA* directory=support dirtype=22 numentries=0
[1999/08/26 16:15:06, 3] smbd/process.c:process_smb(615)
   Transaction 160 of length 39
[1999/08/26 16:15:06, 3] smbd/process.c:switch_message(448)
   switch message SMBdskattr (pid 14500)
[1999/08/26 16:15:06, 3] smbd/reply.c:reply_dskattr(1125)
   dskattr dfree=22296
[1999/08/26 16:16:06, 3] lib/doscalls.c:dos_ChDir(336)
   dos_ChDir to /var/log/samba

And whoops, one dptr got lost here, as you can see if you issue another 
"dir L:\support\mga*.". Win95 doesn't show this behaviour, I
haven't tested NT.

I'm not sure if this is a bug in Win98 or Samba. As our application is 
scanning the directory every few seconds, this dptr leak locks up the smbd 
a few times a day. I'm currently testing a workaround using
"mga?????" as a
mask which doesn't seem to leak dptrs.

On a side note, during debugging I got a 500MB (!) logfile, even though the 
maximum size is set to 1 MB. It seems the rotating doesn't work well at 
higher load.

Franz.