linux 2.2.19/rh6x I use in a share veto files = /.*/ whenever you connect to it the client process hangs, the smbd starts consuming cpu time and cannot be killed but with "kill -9". This is the last part of the smbd log [2002/05/16 05:49:51, 3] smbd/sec_ctx.c:set_sec_ctx(319) 3 user groups: 100 6 19 [2002/05/16 05:49:51, 3] smbd/trans2.c:call_trans2findfirst(863) call_trans2findfirst: dirtype = 22, maxentries = 512, close_after_first=0, clo se_if_end = 1 requires_resume_key = 1 level = 260, max_data_bytes = 65535 [2002/05/16 05:49:51, 3] lib/util.c:unix_clean_name(387) unix_clean_name [/*] [2002/05/16 05:49:51, 3] lib/util.c:unix_clean_name(387) unix_clean_name [*] [2002/05/16 05:49:51, 3] lib/util.c:unix_clean_name(387) unix_clean_name [./] Then it starts running out of control. I don't know if it started with 2.2.4 or 2.2.3; I'm quite sure it worked with 2.2.2. Anyone with similar experiences? -- giulioo@pobox.com
On Thu, 16 May 2002 14:13:32, Thierry ITTY <thierry.itty@besancon.org> wrote:>no experience about it but this could be some funny kind of dead loop, >samba trying to consider . or .. (directories) as vetoed files > >i'd try some more restrictive pattern, like .??* which means "veto files >beginning with dot and whose name is more than 2 bytes longveto files = /.??*/ veto files = /.?*/ do work (dot files not shown, and normal smbd behavior) Thanks -- giulioo@pobox.com
On Thu, May 16, 2002 at 01:47:30PM +0200, Giulio Orsero wrote:> linux 2.2.19/rh6x > > I use in a share > > veto files = /.*/ > > whenever you connect to it the client process hangs, the smbd starts > consuming cpu time and cannot be killed but with "kill -9". > > This is the last part of the smbd log > > [2002/05/16 05:49:51, 3] smbd/sec_ctx.c:set_sec_ctx(319) > 3 user groups: > 100 6 19 > [2002/05/16 05:49:51, 3] smbd/trans2.c:call_trans2findfirst(863) > call_trans2findfirst: dirtype = 22, maxentries = 512, close_after_first=0, > clo > se_if_end = 1 requires_resume_key = 1 level = 260, max_data_bytes = 65535 > [2002/05/16 05:49:51, 3] lib/util.c:unix_clean_name(387) > unix_clean_name [/*] > [2002/05/16 05:49:51, 3] lib/util.c:unix_clean_name(387) > unix_clean_name [*] > [2002/05/16 05:49:51, 3] lib/util.c:unix_clean_name(387) > unix_clean_name [./] > > Then it starts running out of control.Can you attach to the process compiled with -g (debug symbols) and get a stack backtrace please ? Jeremy.