Hello, I was very hopeful when I saw 2.2.7a released to have working large file support with smbclient. However, this does not seem to be fully working yet at this time. smbclient does appear to be working but the tar command of smbclient is not working. This testing was done with a Windows 2000 server and the 2.2.7a release. All testing was done on a Solaris 7 sun4u machine. More information (config logs, etc) is available upon request.
The first problem noticed was that the size of the tar when a dry run was done is incorrect. (edited slightly for users/ips/etc) $ /tmp/samba/build/bin/smbclient '\\server\backups$' -U backups -Tc /dev/null added interface ip=128.10.123.12 bcast=128.10.123.255 nmask=255.255.255.0 Password: Output is /dev/null, assuming dry_runDomain=[DOMAIN] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] tar: dumped 12 files and directories Total bytes written: 7918854144 Now at first glance, there is obviously one formatting mistake. The "Output is /dev/null.. " line needs a trailing \n in the DEBUG call. This is line 1871 of clitar.c The total bytes written is ~8GB which looks good.. except for one thing.. there is actually in excess of 25GB in that directory. Checking with smbclient manually shows the correct value. $ /tmp/samba/build/bin/smbclient '\\server\backups$' -U backups added interface ip=128.10.123.12 bcast=128.10.123.255 nmask=255.255.255.0 Password: Domain=[DOMAIN] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] smb: \> ls . DA 0 Sun Dec 15 20:00:27 2002 .. DA 0 Sun Dec 15 20:00:27 2002 file1.bkf 62926848 Fri Dec 13 23:00:37 2002 file2.bkf A 5097509888 Sun Dec 15 20:10:02 2002 file3.bkf 41955328 Mon Dec 9 23:00:32 2002 file4.bkf 47198208 Wed Dec 11 22:00:36 2002 file5.bkf 378436608 Fri Dec 13 21:04:59 2002 file6.bkf A 3016323072 Sun Dec 15 17:27:51 2002 file7.bkf 378746880 Mon Dec 9 21:05:06 2002 file8.bkf 368723968 Wed Dec 11 21:05:04 2002 file9.bkf 317859840 Fri Dec 13 22:14:58 2002 file10.bkf A 18416276480 Sun Dec 15 20:26:46 2002 file11.bkf 900874240 Mon Dec 9 22:20:13 2002 file12.bkf 366853120 Wed Dec 11 22:15:55 2002 35000 blocks of size 1048576. 4368 blocks available smb: \> du 35000 blocks of size 1048576. 4368 blocks available Total number of bytes: 29393684480 As you can see, file10 alone is 18GB.. far more than the 8GB reported. At least smbclient does report the right value here though. This part was broken as well in 2.2.7. Next step for us was to run the tar command in debug mode, to see if we could find anything obvious. Running with -d 3 you get a little more insight into the problem.. $ /tmp/samba/build/bin/smbclient '\\server\backups$' -d 3 -U backups -Tc /dev/null Initialising global parameters params.c:pm_process() - Processing configuration file "/tmp/samba/build/lib/smb.conf" added interface ip=128.10.123.12 bcast=128.10.123.255 nmask=255.255.255.0 Output is /dev/null, assuming dry_runClient started (version 2.2.7a). resolve_lmhosts: Attempting lmhosts lookup for name server<0x20> resolve_hosts: Attempting host lookup for name server<0x20> Connecting to 128.10.123.54 at port 139 Password: Domain=[DOMAIN] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] received 14 entries (eos=1) skipping file of size 62926848 bytes skipping file of size 802542592 bytes skipping file of size 41955328 bytes skipping file of size 47198208 bytes skipping file of size 378436608 bytes skipping file of size -1278644224 bytes skipping file of size 378746880 bytes skipping file of size 368723968 bytes skipping file of size 317859840 bytes skipping file of size 1236407296 bytes skipping file of size 900874240 bytes skipping file of size 366853120 bytes tar: dumped 12 files and directories Total bytes written: 7918854144 Two interesting things to note here. The printing is obviously borken. There is no associated file name to the sizes and the sizes are also borken. They are wrapping so are likely being stored in too small of a type. Checking the source shows they are size_t's being printed as ints. This obviously does not work. It seems likely that the values are being wrapped elsewhere in the code as well, resulting in the wrong total value. I briefly looked at it and it appears to be the case but I don't have the time to try and change all the types everywhere. Its also interesting to note that if you run with -d A (and the same rest of the command) you get a core dump when it attempts to print the file sizes. Not sure what else -d A does but it does seem to catch the missing file name (as it coredumps at the point that it should be printing them.) $ /tmp/samba/build/bin/smbclient '\\server\backups$' -d A -U backups -Tc /dev/null <excessive-output-snipped> received 14 entries (eos=1) Segmentation Fault (core dumped) Adding finfo.name = finfo1 -> name; to the list of properties copied around 645 adds the file name to the output correctly as well as preventing the segfault (though I suppose that could be coincidental.) This probably isn't a proper fix however given that if the if statement is not evaluated and it goes through the else then finfo.name is still not being set. Something should probably be added there as well. So basically, this email tried to point out one major problem, that large files + smbclient + tar do not work, probably due to too small of types being used to store the file sizes. There were also two minor formatting issues reported as well; missing \n in a DEBUG() and failure to set finfo.name before using it in another DEBUG(). Please let me know if more information is required, I've probably done about as much debugging on this problem as I care to.. I don't have the time nor expertise to rewrite clitar.c to handle large files correctly. -b