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...
Created attachment 1235 [details]
Level 10 debug log of a failed session
I forgot to mention more precisely : this is Debian bug 309798 :
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
I notice this WHATSNEW entry for 3.0.13, which looks like it may be related:
o Jeremy Allison <firstname.lastname@example.org>
* Fix last entry offset in cli_list_new() when using a
FindFirst/FindNext info level of 0x104.
Will investigate further.
Hah. The change that broke this was libsmb/clilist.c r5967:
Fix typo bug where flags overwrote info level.
The diff itself is:
--- 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.
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_REQUIRE_RESUME|FLAG_TRANS2_FIND_CLOSE_IF_END, samba4 sets only
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.
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
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 :-).
Ok, I think I know what the problem is and how to fix it. First I'm going to
ensure I can reproduce it....
Created attachment 1242 [details]
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.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.