I found a bug while trying out a smbclient ls command:
# smbclient //server/data -U%
Domain=[SERNET] OS=[Unix] Server=[Samba 3.5.8]
smb: \> ls
NT_STATUS_NO_SUCH_FILE listing \*
Interestingly a second "ls" works just the first one always fails like this. In the capture and logs you see that the first FIND_FIRST2 call is not UTF-16 encoded, the second one is:
First (broken) "*" on the net is "2A 00"
Second (correct) "*" on the net is "00 2A 00 00 00"
Valgrind output reveals that the problem seems to be in the generic libsmb code:
==18895== Conditional jump or move depends on uninitialised value(s)
==18895== at 0x2F8EED: push_string_base (charcnv.c:1650)
==18895== by 0x23A221: clistr_push_fn (clistr.c:48)
==18895== by 0x234863: cli_list_new (clilist.c:285)
==18895== by 0x235228: cli_list (clilist.c:684)
==18895== by 0x1E4F71: do_list (client.c:839)
==18895== by 0x1E56FA: cmd_dir (client.c:890)
==18895== by 0x1E2345: process_command_string (client.c:4123)
==18895== by 0x1E3B75: main (client.c:4577)
(the line numbers match on 3.5.8 code)
and finally I was able to see this bug on several x86_64 machines (with 3.4 and 3.5) but not on a i586 32bit machine.
this does no longer happen with 3.6.0 but still with the latest 3.5 release.
as written before this was with 3.5.x and 3.6 was okay. Closing bug as fixed.