This is probably still related to the issue reported in Debian bug 302771: http://bugs.debian.org/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 irc.debian.org). 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 : http://bugs.debian.org/cgi-bin/bugreport.cgi?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 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.
Hah. The change that broke this was libsmb/clilist.c r5967: Fix typo bug where flags overwrote info level. Jeremy. 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 */ - SSVAL(param,4,(FLAG_TRANS2_FIND_REQUIRE_RESUME|FLAG_TRANS2_FIND_CLOSE_IF_END)); /* resume required + close on end */ + SSVAL(param,10,(FLAG_TRANS2_FIND_REQUIRE_RESUME|FLAG_TRANS2_FIND_CLOSE_IF_END)); /* resume required + close on end */ p = param+12; p += clistr_push(cli, param+12, mask, sizeof(param)-12, STR_TERMINATE); 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 goes on...
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 :-). Jeremy.
Ok, I think I know what the problem is and how to fix it. First I'm going to ensure I can reproduce it.... Jeremy.
Created attachment 1242 [details] Proposed patch
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. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.