smbclient tar & large files broken on 2.2.7a

[Brian Poole]

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