Bug 2729 - smbclient hangs while listing directories on XP servers
smbclient hangs while listing directories on XP servers
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools
All Linux
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2005-05-20 01:37 UTC by Christian Perrier
Modified: 2005-08-24 10:15 UTC (History)
3 users (show)

See Also:

Level 10 debug log of a failed session (18.30 KB, application/octet-stream)
2005-05-20 01:40 UTC, Christian Perrier
no flags Details
Proposed patch (2.42 KB, patch)
2005-05-26 12:35 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Perrier 2005-05-20 01:37:56 UTC
This is probably still related to the issue reported in Debian bug 302771: 
However, 302771 was reported to be over with the 3.0.14a-1 Debian package. 
Here the difference is that smbclient just apparently "hangs" while trying to 
list a share on an XP server with "lot" of files in it. 
The "ls" command just never return anything and smblclient keep eating the CPU 
and slowly eating memory. Hitting Ctrl-C of course stops the nightmare..:-) 
I will attach a level 10 output of such a session. Feel free to contact me, or 
Steve Langasek, or Eloy Paris, either my mail or on IRC (bubulle or vorlon on 
This issue is currently marked release critical for the smbclient package in 
Debian and we are in the very late release days...
Comment 1 Christian Perrier 2005-05-20 01:40:16 UTC
Created attachment 1235 [details]
Level 10 debug log of a failed session
Comment 2 Christian Perrier 2005-05-20 21:59:10 UTC
I forgot to mention more precisely : this is Debian bug 309798 : 
Comment 3 Steve Langasek 2005-05-25 03:08:37 UTC
This bug has been identified as being specific to shares hosted on VFAT
partitions:  if the share is on NTFS the server responds fine, but if it's on
VFAT, the server will always respond to FIND_NEXT2 requests with the same data
as before.

I notice this WHATSNEW entry for 3.0.13, which looks like it may be related:

o   Jeremy Allison <jra@samba.org>
    * Fix last entry offset in cli_list_new() when using a 
      FindFirst/FindNext info level of 0x104.

Will investigate further.
Comment 4 Steve Langasek 2005-05-25 05:05:26 UTC
Hah.  The change that broke this was libsmb/clilist.c r5967:

 Fix typo bug where flags overwrote info level.

The diff itself is:

Index: clilist.c
--- clilist.c   (revision 5723)
+++ clilist.c   (revision 5967)
@@ -205,7 +205,7 @@
                        SIVAL(param,6,0); /* ff_resume_key */
                        /* NB. *DON'T* use continue here. If you do it seems
that W2K and bretheren
                           can miss filenames. Use last filename continue
instead. JRA */
/* resume required + close on end */
       /* resume required + close on end */
                        p = param+12;
                        p += clistr_push(cli, param+12, mask, sizeof(param)-12, 

So, this call has never worked at info_level 260 before -- smbclient was just
conveniently failing to select info_level 260 due to this other bug.  I've
confirmed that it works if setting the info_level to 1.  And apparently it also
works if setting it to 6. :)  Just not when setting it to 260.
Comment 5 Steve Langasek 2005-05-25 07:26:50 UTC
It looks like samba4 has no trouble getting a valid directory listing in this
case.  Poking around at the source, there's a difference in the flags the two
clients set -- 3.0.14a is setting
FLAG_TRANS2_FIND_CLOSE_IF_END.  If I edit 3.0.14a's flags to match what samba4
does here, I appear to get sane client behavior again.

I'll attach the patch for this shortly.  Can somebody sanity-check this for me?
 I'd like to get this fix into the Debian packages for sarge if it's correct,
which will need to happen this week.
Comment 6 Steve Langasek 2005-05-25 07:51:57 UTC
Gar... sorry, no, when I went back and looked at the version I had working, I
found that it was because I had readded FLAG_TRANS2_FIND_CONTINUE. :/  The hunt
goes on...
Comment 7 Jeremy Allison 2005-05-25 07:55:31 UTC
Great - finally some progress. Now I know it only happens with
a VFAT filesystem I can create a vmware disk with vfat and export
it from W2K3 to W2k3 with my standard 6000 files / directory.
Then let's see what happens when a W2K3 client lists the directory,
and what flags it uses (the client may use different flags depending
on filesystem type, wouldn't that be awful - and so typically Microsoft :-).
Comment 8 Jeremy Allison 2005-05-26 11:59:11 UTC
Ok, I think I know what the problem is and how to fix it. First I'm going to
ensure I can reproduce it....

Comment 9 Jeremy Allison 2005-05-26 12:35:31 UTC
Created attachment 1242 [details]
Proposed patch
Comment 10 Jeremy Allison 2005-05-26 12:38:57 UTC
I've reproduced and now fixed this sucker. Thanks for the help - the key issue
to reproduce it was a FAT32 drive - resume keys are *essential* here, not on NTFS.
Comment 11 Gerald (Jerry) Carter 2005-08-24 10:15:46 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.