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